UMA telecon 2011-10-13

Owned by Former user (Deleted)
Last updated: Oct 14, 2011Version comment
8 min read

UMA telecon 2011-10-13

Date and Time

  • WG telecon on Thursday, 13 Oct 2011, at 9-10am PT (time chart)
    • Skype line "C": +9900827042954214
    • US: +1-201-793-9022 (other int'l numbers) | Room Code: 295-4214

Agenda

  • 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

As of 13 Oct 2011 (pre-mtg), quorum is 6 of 11.

  1. Alam
  2. Catalano, Domenico
  3. D'Agostino, Salvatore
  4. Fletcher, George
  5. Hardjono, Thomas
  6. Maler, Eve
  7. Morrow, Susan
  8. Szpot, Jacek
  9. 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., “Web Host Metadata,” May 2011.) hostmeta. For example, if the "am_uri" is "am.example.com", the requester creates the URI "https://am.example.com/.well-known/host-meta" and performs a GET request on it."

Is this too specific to the human-driven requester app use case? Should it be moved down? Is a GET appropriate? Susan notes that they use a POST so they can sign the message and preserve certain URL information. The problem with POST redirects are "ugly" from a UX perspective because, at a minimum, the window flashes if JavaScript is turned off. If you have JavaScript turned on, which is typical when the requester app is browser-based, it's not so bad. Should we dictate that a POST redirect happen over SSL? That would be good especially if we think PII might flow over this connection. It would be okay to allow either one, but possibly indicate what constraints we want applied to each. Or we could make one mandatory and the other optional. In this case, GET should be mandatory and POST should be optional (because requester apps will have their own natural motivations for using it when the time is right), and we should supply a brief rationale in the spec for why you MAY want to use POST.

What would distinguish the human-driven redirect case from the autonomous redirect case? Maybe nothing. They both need a redirect URL and a callback URL. We also need a state parameter, to avoid replay attacks. We should borrow this directly from OAuth 2.0 language.

Therefore, this information should go in Section 3.5, so it can be factored out to apply to Section 3.5.x.

"The requester performs a GET on the permission endpoint, using the standard HTTP "Accept" header to express the acceptable media type(s) of any claims-requested response."

This has to be expanded and code examples provided, as discussed just above.

"The AM responds in one of three ways: • If the AM requires no claims (or no further claims) from the requester in order to grant authorization for the asked-for permission based on user policy, it gives a success response, indicating that the requested scope has been associated with the requester's token. • If the requester is definitively not authorized for this permission according to user policy, the AM responds with a failure response and the authorization request phase ends. • If user policy demands more information from the requester, the AM responds with a claims-requested response. The list SHOULD use the claim format media type that was indicated by the requester as acceptable."

We'll base the spec details for the first two bullets off what Jacek supplies. (smile) The third bullet would go away entirely, though it may be a pattern we exploit in a Section 3.5.1.x later for the autonomous requester app use case. E.g., it could be smart enough to proactively supply claims, or supply them in response to a request for claims.

It's safe for us to specify the permission success condition (the first bullet) in Section 3.5, because it applies to all flows. But the failure condition could have sub-cases, such as the AM believing that the human being (or browser) that was redirected to it by the requester app is malicious. So Section 3.5 should have the AM response being a SHOULD, not a MUST, to allow for a variety of appropriate remediations. Section 3.5.1 could mention that a malicious-human rationale could apply to the case of not returning a permission failure. In those cases, an option it MAY want to exercise is using further error descriptions.

"The claims-requested list MAY contain internal logic that gives a choice or other variability around the sets of claims that will satisfy the request. This potentially allows the requester to select a subset of claims to supply in order to obtain the needed permission. ... If claims are requested and the requester wishes to provide them, it POSTs another permission request, providing one or more claims or references to one or more locations where the AM can go to retrieve claims. ... The AM responds with a successful or unsuccessful access token response, or with another claims-requested response. This loop can be run through as many times as necessary for the AM to request further claims and the requester to supply them, re-asking for authorization to get the needed permission at every juncture. ... If the content-type of the request is not recognized by the AM, the AM MUST reject the document."

This should all be removed.

"This specification does not define the formats of claims-requested lists and appropriate responses. It may ultimately put minimum conformance requirements on requesters and AMs to handle particular claim formats defined in other specifications, as well as specifying requirements that claim formats seeking consideration for use in UMA must meet. Currently the claim formats that an AM can declare in its metadata (Section 2.1.1 (AM Endpoints)), are as follows: • OpenID?Connect?Fmwk (Sakimura, N., “OpenID Connect Framework 1.0,” June 2011.) (see Section 3.5.1.1 (AM as an OpenID Connect RP)below for further context)."

This should all be removed, and Section 3.5.1.1 should explicitly mention its connection to the claim_formats="openid" option.

Let's go through the Section 3.5.1 text.

"UMA plans to build in a conformance option for the AM to support the AM being simultaneously a standard OpenID Connect RP/client. This has the advantage of the AM having the capability to support the reserved set of OpenID Connect claims. (For the OpenID Reserved Claims see Section 3.3.2 ofOpenID?Connect?Standard (Sakimura, N., “OpenID Connect Standard 1.0,” September 2011.) ). ... Being an OpenID Connect RP/client allows the the AM to be a client to the OpenID Provider. In particular it allows the AM to forward a received OpenID ID-Token (from a UMA Requester) to the OpenID UserInfo Endpoint, and in return obtain the claims associated with the Requester. In this way a strong level of binding is achieved between the authentication event (where the OpenID Provider authenticates the OpenID client or UMA requester) and the claims delievered by the OpenID UserInfo Endpoint to the AM. ... In summary the OpenID Connect provides authentication, authorization, and attribute transmission capability. The integration approach would treat the claims-seeking UMA AM as an OpenID relying party and OpenID Connect claims client, leveraging OpenID Connect mechanisms to transmit claims from distributed sources."

Most of this is going to have been repeated in Section 3.5.1.1 anyway. We think Section 3.5.1 should just state that a number of claims-requesting options are possible, and one is (so far) specified as an option in this spec, and custom options are possible, for which it is RECOMMENDED that an extension for claim_formats be defined and published in a formal extension spec to UMA.

Let's go through the Section 3.5.1.1 and Section 3.5.1.2 text.

We think Section 3.5.1.2 can be removed at this point, given the text that will go in the intro just above.

For Section 3.5.1.1, first of all, see all the instructions above.

How would AMs support additional custom claims? Since they'd have fully qualified URLs, this would be a nice smooth mechanism for an AM to list the ones it supports if it has to. We already allow extensions in the XRD metadata. But maybe there's no point in having the AM advertise to requester apps what claims it may be requesting. Perhaps the real audience for this kind of info is prospective authorizing users! That's because the kinds of claims the AM can handle will influence and be influenced by the policy feature set it wants to provide to its users. So maybe this doesn't have to be machine-readable.

"In the approach of building in a conformance option for the AM being a standard OpenID Connect RP/client, it is assumed that a requester application is being driven by a human person. The requester application would redirect the human user to AM, where the user would engage the AM (through a given interface), leading the AM to obtain the set of relevant claims from the OpenID UserInfo Endpoint. This approach follows closely the OAUTH2.0 authorization code flow. In the future UMA may also develop a corresponding "implicit flow" based on the OAUTH2.0 implicit grant flow."

"In this scenario, the AM Relying Party Interface is responsible for authenticating the subject (namely the UMA Requester) and initializing the OpenID Connect protocol. The AM Claims Client Interface is responsible for requesting claims (expressed in the OpenID UserInfor format) using OpenID Connect protocol in order to satisfy the UMA authorizing user's policy. This client interacts with the OpenID Connect authorization server to obtain a specific access token to access to the subject's (UMA Requester) UserInfo Endpoint (ie. the trusted claims provider)."

This all seems overcome by the instructions that already appear above.

Next Meetings

  • WG F2F on Thursday, 20 Oct 2011, at 1-5pm PT (time chart) in Redwood City, CA, USA
  • WG telecon on Thursday, 27 Oct 2011, at 1-5pm PT (time chart)
  • NOTE: Daylight saving ends Oct 30 in UK and Nov 6 in US; beware of "summertime skew"