[WG-UMA] Notes from UMA/AXN working session

Eve Maler eve at xmlgrrl.com
Mon Dec 10 20:08:37 EST 2012

Thanks for this detailed reading. There are probably some places sprinkled in the UMA core spec (I'm primarily thinking of the Sec 1 and Sec 3 introductory material) where we could clarify UMA's "profile" relationship to OAuth. Thomas, want to take a look and adjust? Thanks!


On 10 Dec 2012, at 11:05 AM, Thomas Hardjono <identity at hardjono.net> wrote:

> Thanks George,
> I’ve updated the example, and also updated the bearer token reference (now pointing to RFC6750).
> /thomas/
> --------------------------------------
> From: wg-uma-bounces at kantarainitiative.org [mailto:wg-uma-bounces at kantarainitiative.org] On Behalf Of George Fletcher
> Sent: Friday, December 07, 2012 4:48 PM
> To: Eve Maler
> Cc: wg-uma at kantarainitiative.org WG; Pamela Dingle; Dave Coxe ID
> Subject: Re: [WG-UMA] Notes from UMA/AXN working session
> My Action Item:
> So it looks like UMA matches RFC 6750 for the permissions ticket flows (Access [E]) *except* for the scheme name used in the WWW-Authenticate response header. My read of RFC 6750 requires the scheme value to be 'Bearer'. However, RFC 6750 explicitly allows additional auth-param attributes to be returned (section 3, 2nd paragraph). So we should be able to switch our scheme from 'UMA' to 'Bearer' and be compliant. 
> Additional tweaks that would make UMA match even more closely, are returning the permission ticket identifier in the 'scope' auth-param of the WWW-Authenticate header (RC 6750 section 3) and adding an 'error' auth-param leveraging the error values defined in RFC 6750 section 3.1.
> So for UMA section 3.1.2 the error response would look like...
> HTTP/1.1 403 Forbidden
> WWW-Authenticate: UMA realm="example",
>   host_id="photoz.example.com",
>   am_uri="http://am.example.com",
>   error="insufficient_scope",
>   scope="016f84e8-f9b9-11e0-bd6f-0021cc6004de"
> In which case we don't need the JSON response body. (We could, of course, also use ticket="016f84e8-f9b9-11e0-bd6f-0021cc6004de")
> For UMA section 3.1.1 we don't need to add the 'error' parameter as RFC 6750 recommends to not respond with an error if no token is presented with the request. We can continue to add the additional auth-params needs to identify the host and AM.
> This would make this section of the spec a compliant profile of RFC 6750.
> Please feel free to double check my read of the spec:)
> Thanks,
> George
> P.S. I only focused on section 3.1 of the UMA spec. It may be useful to look at all calls that use 'Authorization: Bearer' and ensure they match RFC 6750 as well.
> On 12/7/12 4:04 PM, Eve Maler wrote:
> AI: George: Establish whether/how we can claim OAuth 2.0 conformance for the Access (E) leg. 
> Eve Maler                                  http://www.xmlgrrl.com/blog
> +1 425 345 6756                         http://www.twitter.com/xmlgrrl
> _______________________________________________
> WG-UMA mailing list
> WG-UMA at kantarainitiative.org
> http://kantarainitiative.org/mailman/listinfo/wg-uma
> -- 
> Chief Architect                   AIM:  gffletch
> Identity Services Engineering     Work: george.fletcher at teamaol.com
> AOL Inc.                          Home: gffletch at aol.com
> Mobile: +1-703-462-3494           Blog: http://practicalid.blogspot.com
> Office: +1-703-265-2544           Twitter: http://twitter.com/gffletch

Eve Maler                                  http://www.xmlgrrl.com/blog
+1 425 345 6756                         http://www.twitter.com/xmlgrrl

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://kantarainitiative.org/pipermail/wg-uma/attachments/20121210/3d550807/attachment-0001.html 

More information about the WG-UMA mailing list