[WG-UMA] Notes from 12 Jan 2011 ad hoc scope call
Eve Maler
Issue (one of several outlined in Eve's email of yesterday): Conveying to the AM the information it needs to properly respond to a requester's request for a token.
Assumptions:
- The only thing the host knows about a so-far-untrusted requester is the nature of its attempted request for access.
- How the requester acquires enough knowledge of the protected resource to attempt access to it is out of scope for UMA.
- How the requester knows "which user" (from its local perspective) is out of scope for UMA.
- The host is the sole arbiter of which abstract resource sets correspond to which actual resources.
Discussion about assumptions: UMA has a goal of being identifier-agnostic, though higher-order tasks that involve UMA somehow (e.g., use cases in which OpenID Connect/Artifact Binding is involved?) might get into identity assertions produced by IdPs. This is where the "trusted claims" issues come in.
- Solution 1: "Requester as smart mule"
Host gives information to requester in the clear, to convey to the AM.
. Pro: Little crypto, no extra web service calls.
. Con: Exposes data the requester has no right to.
- Solution 2: "Requester as dumb mule"
Host gives encrypted information to requester, to convey to the AM.
. Pro: No extra web service calls.
. Con: Requires host/AM "prearranged key infrastructure" to manage this trust relationship, with attendant additional endpoints and sub-protocols.
Discussion about solution 2: It doesn't have to be PKI; it could use symmetric keys. If we wanted to solve for prearranging this key infrastructure, we could use the existing host/AM back channel, and the way it's forged, to manage it. Ideally we wouldn't define this just for our own UMA purposes, but rather point to some spec module defined elsewhere (such as a JSON Web Token key discovery spec; this is being worked on). UMA's tendency to define "naive"/non-crypto solution paths is useful for highlighting the lack of interoperability and, in some cases, the lack of any solution at all for higher-security ways to solve problems, and also lets web developers inform us their various breaking points for crypto tolerance. But this means the "naive path" through UMA's protocol will remain at a very low "level 0 or 1" of assurance/security. (We mean "assurance" here only metaphorically, not in the true NIST 800-63 sense.) The forthcoming OpenID Connect/Artifact Binding spec ha
s examples we can leverage in specifying our own solutions.
- Solution 3: "Referral resource and artifact"
Host creates a referral resource at the AM on a back channel, and gives the requester only a pointer to it.
. Pro: Secure, allows referral to have lots of useful info in it.
. Con: Requires extra web service calls, requires more endpoints and sub-protocols.
Discussion about solution 3: We can think of this as the ultimate "dumb mode", in the sense that the host doesn't have to do any hard work, and can repeatably and interoperably do the right thing by forcing the AM to pick up the slack. But we realize that it comes with big performance question marks, and a "smart mode" that can leverage all the JWT signing/encrypting work that's starting to mature now could be a helpful alternative that lets us choose solution 2 instead.
General discussion:
The problem overall is to somehow force-rank our design principles "correctly". Our goals for sequestering complexity, crypto, adoption, and simplicity all play into this. Solution 3 suggests itself as a solution for today (or even for "UMA 1.0"?), with a hoped-for solution 2 in the future -- how near, we're not sure! Could we use the "artifact" notion more literally? We should perhaps see the referral artifact as a temporary request token that the requester can use at the AM in order to ask for the access token it needs. We could sort of square the circle between solutions 2 and 3 by leaving it conceptually open exactly what sort of artifact the host *can* (in future?) give the requester. If the host actually gets it from the AM, it makes it the AM's problem entirely.
AI: John: Send email describing this proposition to the UMA list.
====
Domenico joined, and we took the opportunity to start talking about trusted claims and the relationship of tclaims as seen by UMA and IdP aggregation of claims from multiple sources as seen by OpenID AB. The two obvious options are "eager aggregation" vs. "lazy aggregation" of claims. Claims can be packaged in such a way that they can be used as access tokens (think of them as being in a WS-Security header rather than as a web service message payload). What are the responsibilities of claims hosts? Which claims hosts, and which other entities, should be capable of packaging claims to make them usable as tokens? This would make them "minters of tokens" (STSs? IdPs?), which is a different and additional role that's worth clarifying. Since our tclaims use cases often involve real IdPs as claims hosts, perhaps this should be an enhanced (profiled/extended) kind of UMA host that does explicitly have this capability. Should an enhanced AM then do something specific with such
claims/tokens, such as aggregate them? It would function very much like a cloud selector if it did so!
To date, we've assumed that requesters are both (a) not very capable and (b) the least trusted entity in the whole UMA picture. Thus, to solve for trusted claims, we have been reluctant to push all the work of finding out where the requesting party's claims are, and convey them in a trustworthy fashion, onto requester apps. Paul believes that, at a conceptual level, the requester is still responsible (on the requesting party's behalf) for supplying claims, and if it delegates the problem to another party, that's not UMA's business. UMA has a particular place in its protocol (step 2) for managing access to arbitrary resources where trusted claims from the requesting side would be useful to get. OpenID AB is trying to solve for getting trusted claims as a part of an SSO session, and binding those claims to that session. (Like SAML!) So the have a fair amount of overlap, but it's not total.
We looked at Domenico's slides for his enterprise-class scenario for tclaims. Could we leverage OpenID AB and have the requesting party's AM be the discovery service and token issuer for access to the various claims hosts, which would be OpenID AB-capable endpoints? OpenID AB puts, into access tokens used to get access to a claim, an identifier that can be used to bind all the various claims being gotten. The identifier can be a pseudonym.
Is it the case that discovery is easier than we thought it might be? It's certainly the case that AM 1 tells requester 1 exactly what claims are needed, such that requester 1 can hand this stuff over to AM 2 (in the fashion Paul described above, "outsourcing" the provisioning of claims to AM 2). AM 2's "claims catalog" could be largely an internal database, which AM 2 compares (locally to itself) to the list of requested claims that came from AM 1.
AI: John: Review Domenico's new tclaims material.
AI: Domenico: Review John's interim OpenID AB draft.
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