UMA telecon 2011-02-24

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

Agenda

• Roll call
• Approve minutes of 2011-02-17 meeting
• Action item review
• Trust model review (revision forthcoming)
• Review rreg changes and issues
• Review changes to scoped-access proposal
  • Old proposal; revision forthcoming
  • Relevant 'pad
• AOB

Attendees

As of 18 Feb 2011 (pre-mtg), quorum is 8 of 14.

1. Adams, Trent
2. Mohammad, Alam
3. Bryan, Paul
4. Catalano, Domenico
5. Maler, Eve
6. Moren, Lukasz
7. Morrow, Susan
8. Scholz, Christian
9. Wolniak, Maciej

Non-voting:

• John Bradley
• Rainer Hoerbe
• Cordny Nederkoorn
• Frank Wray

Regrets:

• Maciej Machulak

Minutes

New AI summary

Roll call

Quorum was reached.

Approve minutes of 2011-02-17 meeting

Minutes of 2011-02-17 meeting APPROVED.

Action item review

• 2010-11-18-4 Eve Open Capture new user stories in the wiki.
• 2011-01-06-4 Susan Closed Write draft UMA trust model.
• 2011-01-27-1 Paul Bryan Open Revise the Claims 2.0 spec to reference and profile JWT.
• 2011-01-27-3 Paul Bryan Closed Revise the "scoped access" flow list to reflect decisions made in today's meeting. Done in the 'pad.
• 2011-02-10-1 Alam Open Share details of his planned UMA demo with the list. Due by end of February.
• 2011-02-17-1 Maciej et al. Closed Examine the SMART implementation to check on the resource set identifier uniqueness implications.
• 2011-02-17-2 Eve Closed Ask for John B.'s help in understanding how OpenID AB Core and the JWT work apply to our usage of the artifact and "meaningful token" design patterns. It appears that UMA will be responsible for specifying our own instances of the "artifact" design pattern, since we're at the "meta-model" level, not the OAuth-mediated access level.

Review changes to scoped-access proposal

See the 'pad. New content produced/reviewed during the call appears here:

How to read the following list:

• Things happen at different times than they used to. Don't think "step 2" vs. "step 3" for now, and be prepared for different loops through the flow.
• "Token verification" is now separate from "authorization checking". Token verification is effectively just authentication of the requester's message, while authorization checking is ensuring that the authorization scopes line up right.
• What we were calling a "referral" in the 2011-01-20 meeting is now a "ticket", and it must be gotten every time the requester wants to add new authorization scopes to its abilities. [Note that this language wasn't carried all the way through the 'pad text; this needs work.]
• We plan only to spec "by reference" ("artifact") versions of all the flows for now.
• Keep in mind that only requesters and AMs talk about claims together, and hosts get into the game only when it comes to authorization scopes. AMs are likely to have to manage and store and keep track of requesters' supplied claims over time.

Discussion:

• "Adding scopes to the token", as stated below, involves just a requester acting autonomously as far as the description goes. But what about Alice-to-Alice sharing? Would you want claim semantics that are specific to the different trust-model constellations?

Step 1.99999999999999999999999999999999999999999999999999:

1. 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.
2. 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.
3. 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).
4. 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.
5. 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.
6. 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.
7. 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?