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.
...