UMA telecon 2011-02-24
Table of Contents | ||||||
---|---|---|---|---|---|---|
|
Date and Time
- WG telecon on Thursday, 24 Feb 2011, at 9-10:30am PT (time chart)
- Skype line "C": +9900827042954214
- US: +1-201-793-9022 | Room Code: 295-4214
...
- Requester attempts to access protected resource at host. This is requester's first time, and so requester will not be sporting an access token. Host will see this, and return a 401 ("Unauthorized", but widely acknowledged to have the semantic "unauthenticated"), with the endpoint where requester can receive a token.
- Requester goes to access token endpoint at the AM and requests one. (The details are largely OAuth-specific; we'll nail those down eventualy.) It gets one with little or no challenge, because the token has no authorizations yet associated with it. In other words, this can be used to uniquely correlate the same requester in all its interactions with this AM and host, but that's it for starters. Later, requester will negotiate authorization scope to be associated with the token to allow access to protected resources.
- Requester now has a nice, fresh, clean token that it can use to request the resource again from host. It tries to do so. Host sees the token. Host verifies the token—to be discussed whether it does this via back channel ("artifact" model) or can do so prima facie ("meaningful token" model). Host asks AM what authorization scopes this requester has at this AM for this host (the host should not be allowed to learn about authorization scopes this requester has for other hosts at this AM). Since the token is fresh and there are no authorization scopes associated with it yet, AM comes back with nothing. Host in turn says 403 ("Forbidden", meaning unauthorized).
- Requester really wants this resource, and is willing to do whatever it takes to get access. It asks host for a "scope-request" ticket, so that requester can take it to the AM to negotiate authorization of the protected resource set without the requester actually knowing the details of resource set taxonomy at the host. This is because we are tin-foil-hat-wearers (TFHWs). This ticket may be by reference ("artifact" model), or by value ("meaningful token" model). In the by-reference case, it points to a concrete data structure that the host registers at the AM, containing information about the requested scope, such that the AM can look it up when the requester presents the ticket to evaluate the scope of authorization being requested by the requester.
- Requester goes to AM requesting authorization, sporting this ticket/ticket reference. AM can deduce the resource set and/or action from it. AM consults its policies for the resource set and action, and decides what claim(s) about the requesting party are required to secure authorization. These required claim(s) are then demanded of the requester.
- Requester acquires the required claim(s), by means that are out of scope. Once it acquires the claim(s), it submits them to AM. It then presents the referral again, and sees that there are no further claims required and authorization is granted. In some cases, there might be more claims required, depending on how policy is established at AM. In other words there may be preliminary claims required, which based on their value would determine if any further claims would be required in support of them. Bottom line, claims negotiation is iterative.
- Now that requester sees that everything is hunky dory, it goes back to host and requests the resource again, with the same access token it received in the first place. Host again validates the token. Host then requests the host-scoped authorizations associated with the token, and sees that access to the resource is granted. Typically, 200.
Now, requester wants to access another resource at host—one for which authorization was not yet negotiated with AM. Again, host returns 403. Again, requester gets referral. Again, requester goes to AM with referral. AM determines required claims based-on policy. AM supplies those to requester. Requester gets claims. Requester supplies claims. Requester confirms no further claims required (iterative). Requester goes back to host and requests resource. Host repeats authorization scope retrieval from AM. AM nows includes it as authorized. Host now gives access to resource for which authorization was newly negotiated.
Now, for whatever reason, one claim supplied to AM out of a dozen is no longer valid—perhaps it expired. Next time host requests authorization scope from AM, AM will now indicate that it is not authorized. Such a subsequent requests would result in the 403 flow. Again, requester goes to AM with referral. This time, only that single claim is required. Requester gets that one claim—not the dozen that are truly required because the others remain valid. Requester supplies "refreshed" claim. Same flows, ultimately gets authorization. Requester goes back to host and successfully accesses resource.
Now, policy has changed because user is more paranoid than before. Next request causes non-authorization. 403. Again, requester goes to AM with referral and negotiates authorization. Again claims. Again iterative. Finally, requester is authorized and now can access resource at host.
Trust model review
Susan, Rainer, Patrick Curry (PKI bridge person), Tom Smedinghoff, Paul Bryan, and Eve have been the ones variously discussing this revised model.
We may want to mention that our "responsible party" is an analog to the more widely used "asserting party" in Rainer's work. The verbs in the "Expected behavior of the responsible party" column of the UMA model are the key responsibilities, though, vs. "asserting" something.
Both authorizing users and requesting parties variously serve as "data subjects" or "principals", depending on which part of the UMA protocol or its use cases are being referred to. E.g., in tClaims, the authorizing user is the subject, and in the claims exchange portion of the UMA protocol, the requesting party (and possibly the requester operator?) is the subject.
In version 1.0 of UMA, we had decided that our scope for "authorizing parties" is just natural persons. This is why we use the specific term "authorizing user" instead of something like "authorizing party". But we didn't have as much luck with the requesting side. This is why a whole bunch of specialized terms are needed for that side.
John B. has been working with folks at Google and others on ensuring that specific instances of client (requester) software can be tracked. If the "requester operator" is you personally, because you control your own PC and the requester is desktop software, then different claims might be demanded than if the requester operator is Google, which runs a cloud service. This is where our old discussions about TaxMonkey use cases comes in. If the app has a unique serial number, that could potentially be used (if it's kept well secured).
Unfortunately, "agent" is both a technical term of art (as in "user agent") and a legal term of art. Is the language we've got for the various requesting parties/tools okay? We'll assume so for now.
Does tClaims deserve a constellation, or does it amount to a trust model all on its own? Maybe trust models are just really big constellations.
The ultimate goal would be that a lawyer could take this, and an instance of a deployment (and possibly the trust frameworks it participates in), they could map the "points of liability" and how to mitigate them. We hope the ongoing work at OIX will help clarify this for us, and we can get a virtuous circle going.
Next Meetings
- WG telecon on Thursday, 3 Mar 2011, at 9-10:30am PT (time chart)
- WG telecon on Thursday, 10 Mar 2011, at 9-10:30am PT (time chart) – Eve regrets; Maciej to chair and publish agenda/minutes?