...
- Roll call
- Approve minutes of 2011-10-06 meeting
- Action item review
- Admin stuff: Next week is a F2F, not a telecon
- UMA core spec review in preparation for new I-D, OpenID Summit, IIW, and UMA F2F
- AOB
Attendees
- TBS
Minutes
TBS
Next Meetings
...
As of 13 Oct 2011 (pre-mtg), quorum is 6 of 11.
- Alam
- Catalano, Domenico
- D'Agostino, Salvatore
- Fletcher, George
- Hardjono, Thomas
- Maler, Eve
- Morrow, Susan
- Szpot, Jacek
- Wray, Frank
Non-voting participants:
- Kevin Cox
Regrets ahead of time: Note that Alam will be away in the month of December.
Minutes
Roll call
Quorum was reached.
Approve minutes of 2011-10-06 meeting
Minutes of 2011-10-06 meeting APPROVED.
Admin stuff: Next week is a F2F, not a telecon
UMA core spec review in preparation for new I-D, OpenID Summit, IIW, and UMA F2F
Paul Bryan has asked for his affiliation as an author to be updated to mention ForgeRock. And we need to add Domenico.
Regarding Section 3.5.1.1 in rev 18, Domenico suggests that "the AM Relying Party Interface is responsible for authenticating the subject (namely the UMA Requester) and initializing the OpenID Connect protocol" needs to be changed. First of all, the subject is really the UMA Requesting Party, not the UMA Requester. The requester's responsibility is just to redirect the human requesting party to the AM, and then the AM's OpenID Connect client functionality needs to take over. This is likely to involve presenting the subject with options for discovering their OpenID Provider, requesting claims, etc. We should cross-reference the OpenID Connect Standard spec and to the OpenID Connect Messages sub-spec where the reserved claims (actually, "reserved parameters") are defined.
This section needs to be normatively connected to the portion of the XRD metadata section (Section 2.1.1) where the "openid" keyword is mentioned (note that it should be "openid", not "openid-connect"). If the AM advertises conformance to that option, it means they have to conform to this section. Should that conformance option still be called claim_formats? What would the other likely values for this category be? We've discussed how an AM could be conformant to Facebook or something else proprietary. Would claim_client_interface be more descriptive? or claim_consumer? Let's keep claim_formats but define this as having a value that covers both claim formats and claim client interfaces etc. for now. The value of this parameter should be extensible, as long as values use "X-" or "x-" in front.
Let's go through the Section 3.5 text.
"In this interaction, the requester asks the AM to grant authorization to associate a new permission to its access token for use at a particular host. It does this at the AM's permission endpoint by supplying the permission ticket it got from the host, along with its requester access token. The AM uses this information to look up the previously registered permission, confirm that the correct requester is asking for it, map the requested permission to operative user policies, and demand in turn that the requester convey any claims needed to support its request."
This seems okay.
_"The requester learns about this endpoint by retrieving the AM's hostmeta document (see Section 2.1.1 (AM Endpoints)) based on the "am_uri" information that was provided by the host in its previous response, as described in Section 2 of hostmeta (Hammer-Lahav, E.,