...
- Thursdays, 9-10am PT
- Skype: +99051000000481 / US +1-805-309-2350 / international lines / web calling interface, code 178-2540# / code 1782540
- Screen sharing: http://join.me/findthomas - NOTE: do not use the join.me dial-in line
- UMA calendar: http://kantarainitiative.org/confluence/display/uma/Calendar
...
- Roll call
- Approve minutes of UMA telecon 2016-06-30
- Logistics
- When/how to extend our design time?
- 8:30-10am PT calls on Thursdays
- 9-10:30am PT calls on Thursdays
- Additional calls on other days
- Multiple options
- How about going long on today's call?
- Spec editorship duties
- When/how to extend our design time?
- For reference: MPD sequence diagram and generic low-level sequence diagram
- MPD writeup on consent
- Is doing consent later okay?
- Is doing consent OOB okay?
- Would an "UMA refresh token" alternative make any sense?
- The Alice-to-Alice sharing mechanism in light of MPD
- Trust elevation extension mechanisms and MPD
- MPD writeup on consent
- Registering multiple resource sets
- Input from George on existing spec text?
- Client awareness of scopes
- Concrete proposals based on multiple-resource-set directions?
- AOB
Minutes
Roll call
tbsQuorum was reached.
Approve minutes
Approve minutes of UMA telecon 2016-06-30: tbs
Breadth-first MPD review
The client request that (potentially) includes scopes is now form-encoded vs. JSON, to align more closely with OAuth.
If Alice's policies say that the client is able to get access (e.g., because it pushed sufficient claims about the RqP that matched the RO's policies and the particular identified client is okay), then the AS could issue an access token right away. This is the final choice outside the loop.
Inside the loop, there are now two choices, vs. three, since there's no AAT. The AS rotates the ticket every time it returns a response to the client, and gives it need_info (with new syntax). The client either "sends claims" to the token endpoint, or "sends the RqP" to the claims endpoint.
With the AAT in the picture, UMA had an in-band way to let the RqP permission the pushing of claims (about them) to the AS. What happens now? We discussed what uma_authorization scope really means. Although UMA Core says "The issuance of an AAT represents the approval of this requesting party for this client to engage with this authorization server to supply claims, ask for authorization, and perform any other tasks needed for obtaining authorization for access to resources at all resource servers that use this authorization server", is it strictly true that Bob would know this in practice? Would UX standards have to be put in place in deployments? Since the AAT was covering an unspecified set of claims, Justin is suggesting that an AAT was insufficiently granular to inform Bob about what was going on. Can we assume the wonderful circumstance that Bob's relevant claims are UMA-protected and therefore the "out-of-band" protection circumstance is ideal for fine-grained protection with Alice's AS?
A typical case, we expect, is a SSO-like pattern where the information the AS needs is pre-negotiated with the client. In the case of a "promiscuous client" that is set up to share a lot of information about Bob, the interactive pattern could be used as a flow to get Bob to approve of, confirm, or consent to sharing that would otherwise happen silently. This would exploit two parts of the loop. If we want to ensure this pattern is available as a regular thing, Bob would get redirected to the claims endpoint at the AS, where Bob has to choose some claims provider that can supply a claim about accepting the client as representing him. The "non-in-band" experience is totally silent = smoother. The "in-band" experience involves a redirect to the AS and then to a claims provider = equal to the current AAT experience if there is a local login, or possibly more involved if there's choice about where to go to get the claim (Eve believes this is true; Justin disputes it). There are now the two options. Will clients have the incentive to go for the smoother option (and will "UMA protection" arise for this)?
AI: Justin: Write up answers in email to the questions above.
Another question: When the RqP = the RO (that is, it's Alice-to-Alice sharing), how would the loop work?
(We closed the formal WG call and continued discussing.)
Right now, the RqP's identity is bound into the AAT. But without the AAT, the client wouldn't have that available. As long as we can provide an identity token in a client-authenticated call, George asks, isn't there a way to solve this? Eve's question is about the use of the claims endpoint vs. the authorization endpoint: If it's Alice, shouldn't she use the latter? Only if it's OAuth vs. UMA. Alice-as-RqP should use the claims endpoint.
George wants a strong proof of Bob. The AAT gave him that, so whatever future mechanisms need to not lose that. Also, the AAT made the semantic of identity (and approval) persistent across a single transaction or session. We discussed how, in the current UMA flow, the client is able to pass in the current RPT to get the next one; we could leverage this pattern in order for the client to provide "Bob context" to the AS at the token endpoint.
Another question: We know that the trust elevation mechanism is gaining attention as a place for extension. How should we ensure this going forward?
Logistics (discussed post-official call)
Since we're once again in design mode, we should strongly consider expanding our meetings to 90 minutes. Would 8:30-10am or 9-10:30am PT be better for people?Deferred.
Logistics
Mike speaks in favor of regular 60-minute calls and additional ad hoc calls among, say, spec editors and interested others. Robert and Justin agree. Okay, we seem to have consensus around that.
Justin has little availability for an editing session next week; Eve will suggest some times for a kickoff session the week of July 18.
MPD writeup
The "claims" endpoint is really the "interaction" endpoint for all purposes.
Justin has introduced a new idea of an "UMA refresh token" (URT!) as a static refresh artifact along with the client presenting the ticket at the token endpoint, to signal a cross-session RqP relationship with the AS. This would be used in concert with a one-two punch of gathering consent at the claims endpoint and then pushing claims at the token endpoint. Eve wonders about the name: It represents the RqP's persistent consent or authorization, even if its function at the AS might be to "refresh" something. James suggests: consent context token.
We have a lot of naming issues to sort out, so let's not decide right away.
We have consensus to proceed with spec text for a mechanism that keeps consent "in-band" vs. "out of band", by virtue of a "token-ish" method that the client uses to preserve the AS's memory of the RqP. If the AS doesn't issue an urt-ish thing, then consent must be sought every session.
What about Alice-to-Alice sharing? If she's sent to the claims endpoint, would we anticipate that it would be collapsed into an authorization endpoint as well, and then have it hand out (say) authorization codes in addition? The client wouldn't be expecting that; it's expecting a ticket. Ultimately, Eve had a re-epiphany about the lack of a need for any special treatment of Alice as an RqP; Alice as an RO can simply make policies about "herself as an RqP" (and the AS could, if it wishes, handle various Alice-to-Alice cases specially if it wishes). Justin would, however, like to see some experimentation where there's some confluence of the two endpoints.
We discussed the "Allow ID Tokens as RPT" thread (correction: it was the "Questions about MPD" thread). An AS needs to have an identified and authorized RqP. Strictly speaking, does that mean the user needs to be "logged in"? James defines this as having had an interactive authentication experience, which his implementation doesn't require; it all depends on what auth modules have been leveraged. Justin's read of the meaning of "logged in" is broader, just meaning "has an authentication session".
We didn't quite get to the topic of trust elevation extension mechanisms, but this will depend on how the spec text shapes up.
Attendees
As of 23 Jun 2016 (post-meeting), quorum is 6 of 11. (Domenico, Kathleen, Sal, Nagesh, Andi, Robert, Agus, Maciej, Eve, Mike, Sarah)
- Domenico
- KathleenSal
- Nagesh
- AndiRobert
- Maciej
- Eve
- Mike
- Sarah
Non-voting participants:
- Justin
- FrançoisAdrian
- John WColin
- James
- Scott
- Justin
- Ishan
- George