UMA telecon 2014-03-20
...
- 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.
...
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
Complex 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
...