UMA telecon 2014-03-20

Date and Time

Webinar 8-9am PT (time chart) - N.B.: US has changed clocks by now - "summertime skew" (UK 7 hours later at 3pm, Europe 8 hours later at 4pm) - be sure to register!
Special post-webinar focus meeting 9-10am PT (time chart) - N.B.: US has changed clocks by now - "summertime skew" (UK 7 hours later at 4pm, Europe 8 hours later at 5pm)
- Voice: Skype: +99051000000481 or US +1-805-309-2350 (international dial-in lines), room code 178-2540#
- Screen sharing: http://join.me/findthomas

Agenda

Webinar debrief
Claim profiles review
Interop planning
AOB

Minutes

Webinar debrief

Jin loved seeing the audit message in Maciej's screenshot. This is very important for the healthcare use case. Eve is very pleased with how the webinar went. She will ask Alex Jones of CA to edit out the snafu bits.

Claim profiling

Spec is here. The need_claims response to a client's request for authorization data to be added to its RPT is one option for a communications channel for saying what the AS can handle. But the configuration data is another. What level of dynamism is appropriate? In Roland's use case, perhaps the client could push a SAML assertion or OpenID Connect claims, because the UMA client is Alice's IdP. So it natively knows stuff about Alice, and could package it up in a token to push that to the AS. It's akin to an "IdP-initiated SSO" flow in that the client logs Alice in, and pushes the assertion unbidden to the AS. So in that case the AS could put the fact that it accepts SAML tokens in its "metadata" (UMA config data). Maciej has proposed that the SAML assertion get base64-encoded before being embedded in the request that the client pushes; this seems normal/fine.

Roland asks: What about using encrypted SAML assertions? It seems they could be encrypted at the SAML level (prior to base64), and/or they could be encrypted at the JSON level (using JWE). If the assertion is just being passed through by the client, it shouldn't be able to read it, so encryption may very well be the right mitigation for that. Do we have to think about changes to Section 3.2 in order to be more receptive to encryption? Mark notes that the SAML 2.0 Profile for OAuth 2.0 Client Authentication and Authorization Grants spec (Sec 3) specifies that a SAML assertion used in this context requires an <Audience> of the intended AS, which would constrain the free flow of random assertions through random clients (which presumably is a good thing!). Should we make reference to this, at least in a non-normative way? Clearly the SAML assertion contents and format would best be profiled specifically for any context where you would be flinging SAML assertions anyway.

OpenID Connect has similar audience restriction capabilities. Does it actually have an equivalent to the SAML bearer token profile? Not really. The ID token just conveys authentication facts (with an option for stuffing user claims into the ID token), and there's still an access token that you get in order to get user claims from the user_info endpoint. So, turning to the delivery option involving OpenID Connect... If the client were to convey the ID token, it might contain claims, but its main purpose is to identify the user, authentication context, and audience – essentially the usual metadata you'd find in an identity assertion. What is current practice around actually putting user claims in the ID token? It was done as optimization syntactic sugar; not clear who's using it. Note that the "OX trust elevation claim profile" done by the Gluu folks makes use of the authentication context, to revoke both the RPT and the AAT of an RqP that authentication too weakly for the policy.

So far, Maciej has sketched out that the client would convey only raw user claims, not an ID token. Doesn't this mean that essential assertion-metadata context would be missing? Mark is interpreting Section 3.3 as saying that user claims strictly adhering to the list of OpenID Connect reserved claims, and those alone, are being passed. The "Hybrid" pattern in Section 3.4, by contrast, allows for flexibility in a private agreement about other claims with other claim semantics that could be passed. Eve was hoping, rather, that our profile that enables the sending of reserved claims should also enable the sending of arbitrary private-semantics claims. Roland has been hoping for OpenID Connect to get more flexible in exactly this respect, because currently if you want to get non-reserved claims from an OP, you have to define a whole new endpoint for it. (Eve sez: Well, darn.) So does this mean that our Hybrid profile should serve as our baseline for OIDC claim profiling? Let's work with that as an assumption for now, and see what trouble we get into.

Introp planning

Regarding complex scopes and resource sets: Roland has working on implementing what's been proposed, and recommends starting to write optional feature tests so that we can play with this a bit.

AI: Roland: Fill out his portion of the interop wiki (http://tinyurl.com/uma1iop) and let us know what's missing from the wiki in terms of matrix cells to fill out.

Attendees

Jin
Eve
SteveO
Sal
Thomas
Zhanna
Adrian
Mark
Roland
Domenico

Next Meetings

All-hands meeting Thu Mar 27 8:30-10am PT (time chart) - N.B.: US has changed clocks by now - "summertime skew" (UK 7 hours later at 3:30pm, Europe 8 hours later at 4:30pm)
Focus meeting Thu Apr 3 8:30-10am PT (time chart) - all back in sync
Focus meeting Thu Apr 10 8:30-10am PT (time chart)
Focus meeting Thu Apr 17 8:30-10am PT (time chart)
All-hands meeting Thu Apr 24 8:30-10am PT (time chart)

Browser not supported