[WG-UMA] Notes from 2 Mar 2011 ad hoc telecon on Claims 2.0
Eve Maler
References for this meeting:
http://kantarainitiative.org/confluence/display/uma/Claims+2.0
http://kantarainitiative.org/confluence/display/uma/Simple+Access+Authorization+Claims
http://self-issued.info/ (for other spec links)
The Claims 2.0 innovation is to request claims by providing a wildcarded template for what the claim should look like. It has a limited capability to specify which of several issuers the claim should come from, and to specify string constraints.
The templating approach is appealing. Should it also have less-than and greater-than, or any other templating characteristics? How far do we want to go with data typing? Handling dates ("before this date") and numbers ("over 18") would be really handy, but we're not sure how far the support would spread. Could we have a standard for < and > and require claims that use them to say what they mean in the claim specification/documentation?
Should it also have syntactic sugar for specifying signature and encryption requirements? Probably not. Token aggregation is a higher-order function that we may not want to optimize for.
Every JWT token has to have an issuer, and it's asymmetrically signed. This requires you to already know them in preconfigured fashion, or be able to look them up dynamically with an intermediary with which they're already registered. So for UMA's self-asserted promises, we'd need an "issuer-less" or implicit-issuer claim. It would be considered low-trust or bearer-trust. So we'd have the option of unsigned claims and signed JWT-based claims.
In JWT, they've talked about a level that just has an integrity check, taking the hash of the HMAC and adding it in the wrapper. This could be handy for making the JSON object look similar regardless of whether there's a signature that needs to be verified, if this is the "lowest level" required vs. the issuer-less case.
A claims host (in our tClaims terminology) is an attribute authority. Sometimes, they may also be an IdP. If a requester is asked to produce claims in UMA's step 2, it is conveying them on behalf of the requesting party (or perhaps a requester operator, if it differs?). We don't believe that the two AMs in a tClaims scenario ever talk directly to each other.
The SAML-OAuth assertion profile is getting close to a draft that specifies exactly what the JWT token would look like, as a fledgling SAML assertion analogue. This is seen as an important deliverable for the next IETF meeting.
JWT has name-value pairs in it (but doesn't anticipate the option of value structure the way we have). And it has a structure for holding multiple claims.
Would it be better to have the claim type (which is a URL) as the key and the claim value as the parameter value? Probably.
Does OpenID ABC package a set of claims together? What's the right way to boxcar this? Would it be useful to assign a single URL to a common set of claims (like "name, rank, and serial number")?
AI: Nat to provide JWT-friendly versions of claims as shown in the SAAC spec.
Eve Maler http://www.xmlgrrl.com/blog
+1 425 345 6756 http://www.twitter.com/xmlgrrl
_______________________________________________
WG-UMA mailing list
WG-...@kantarainitiative.org
http://kantarainitiative.org/mailman/listinfo/wg-uma