UMA telecon 2011-02-24

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

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

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

Non-voting:

Regrets:

2011-02-24-1	Eve	Open	Set up a focused ad hoc call on "Claims 2.0" and recent JWT progress, with participants ideally including Nat and Mike Jones along with key UMAnitarians.
2011-02-24-2	Susan, Eve	Open	Revise trust model according to the discussion from 2011-02-24.

Quorum was reached.

Minutes of 2011-02-17 meeting APPROVED.

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.

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:

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