UMA telecon 2011-01-13

Owned by Former user (Deleted)
Last updated: Jan 13, 2011Version comment
6 min read

UMA telecon 2011-01-13

Date and Time

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

Agenda

  • Roll call
    • Eve regrets for next week; Maciej to chair
  • Approve minutes of 2011-01-06 meeting
  • Action item review
  • Conformance ad hoc call: report and discussion
    • See the "questions we need to answer" in the meeting notes
    • Terminology? (minor)
  • Scope ad hoc call: report and discussion
  • Trusted claims: review and discuss proposal materials
  • AOB

Attendees

As of 6 Jan 2011 (pre-meeting), quorum is 8 of 15.

  1. Mohammed, Alam
  2. Battersby, Paul
  3. Catalano, Domenico
  4. D'Agostino, Salvatore
  5. Hardjono, Thomas
  6. Machulak, Maciej
  7. Maler, Eve
  8. Moren, Lukasz
  9. Morrow, Susan
  10. Scholz, Christian
  11. Wolniak, Maciej

Non-voting:

  • John Bradley
  • Frank Wray
  • Cordny Nederkoorn

Regrets:

  • Paul Bryan

Minutes

Roll call

Quorum was reached.

Eve regrets for next week; Maciej M. will chair.

Approve minutes of 2011-01-06 meeting

Minutes of 2011-01-06 meeting APPROVED.

Action item review

  • 2010-11-18-4 Eve Open Capture new user stories in the wiki.
  • 2011-01-06-1 Paul Bryan, Sal Open Come up with a recommendation for using or fixing JWT to solve the requester authentication/correlation problem in Step 3.
  • 2011-01-06-4 Susan Open Write draft UMA trust model. Under way. She's working with Rainer to consider using his meta-model, and Paul Battersby is helping with the drafting.
  • 2011-01-06-5 Paul Bryan Open Draft scoped-access multiple-tokens email. Now closed.
  • 2011-01-06-7 Eve Open Create new websequencediagrams.com diagrams for the UMA protocol flow.

Conformance ad hoc call: report and discussion

We agree that UMA 1.0 should probably allow for static credentialing/trust-building that's out of band of UMA. Should we explicitly still allow for totally dynamic but likely totally untrustworthy dynamic client credential provisioning during Step 1? John notes that dynamically provisioning a set of symmetric keys opens you up to DoS attacks. We currently call out from UMA Core to the OAuth dynamic client registration I-D we had written, but it's not very normatively stated.

We should soften this to say simply that the host is required to have OAuth client credentials, but not say how. This will make a cleaner break between the UMA Core spec and future developments in the dynamic client registration and trust-building space. The proper place for metadata that claims support for dynamic credentialing is probably the "upper-level" space.

Just to be clear, OAuth client credentials for this host at this AM reflect this host/AM pair (possibly unique or possibly "anonymous", if the AM offers this as an option for OAuth client credentials). The host access token that it eventually wins on behalf of an authorizing user reflects this unique host/AM/user triple.

So, answering the "questions we need to answer" from the meeting notes:

  • Does the AM have to declare ahead of time (maybe in its metadata) whether or not it supports dynamic client registration and, if so, what standard it supports for doing so? No, this wouldn't be part of UMA for now. It could be a commonly implemented AM extension someday.
  • What should the host's behavior be if it can't successfully get client credentials after the user has said "Use this AM"? The host has complete control of how it presents AM introduction opportunities to the user, and it has the right to indicate that the user must select from a short list.
  • The AM's decisions around client credential provisioning (whether dynamic or static) are intimately bound up with trust models. For example, it might require static provisioning so as to "whitelist" specific hosts. Or eventually we might profile UMA further to allow for dynamic demands for claims during step 1 to ensure that the host meets trust framework liability requirements. This would mean that the AM might refuse a host's attempt to connect, if the host is more expansive in its willingness to trust than the AM is. If the host happens to be wrong in its assumption that it can successfully perform a web-server user-authorization flow, we think this is initially an OAuth-layer error akin to "wrong client credentials". The AM has an opportunity to present an explanatory message to the user at the time of the redirect.
  • The host may itself want to make trust model decisions about the AMs it is willing to work with. This could be reflected in the host only offering to connect to a small subset of "whitelisted" AMs on the user's behalf, or by other more dynamic means. What should happen to the UX in this case? As already noted, the host has complete control of how it presents AM introduction opportunities to the user, and it has the right to indicate that the user must select from a short list.
  • UMA doesn't want to solve all the trust model problems in the world, but if hosts and AMs respectively could present third-party-asserted claims about their participation in trust frameworks, then the UMA step 1 process could take advantage of them. This is for UMA V.next!

Scope ad hoc call: report and discussion

We reviewed the assumptions made in that meeting. John comments, regarding the assumption about the host's exclusive understanding of what's in a resource set: What about having the AM generate a shareable link that stands for the host's actual resource (as Domenico has sketched previously in his wireframes)? Would that mean that the requester visits the AM first? We still intend, so far, to preserve the UMA use case to share links with requesters that go directly to the host, where the resource is nonetheless protected. (This could be called "public URL but protected resource".) There are also use cases where the URL can't be made public either. Does it make sense to have an AM-rooted URL for those, and if so, does this allow for protocol optimizations or does it impose protocol costs? It could provide a clean opportunity for solving our old topic of "resource baskets" (which Domenico also sketched).

Coming back to the primary issue discussed in that meeting, we discussed the idea of "squaring the circle" between the second and third solutions proposed. The AM would have the choice to be stateless and put everything in the token, or be stateful and store the referral info in a local database, which helps with scaling to handle thousands of AM servers across the world. The requester would be none the wiser about whether the thing it's given is a mere artifact (small blog) or an encrypted token (large blog). The host also doesn't have to worry about doing any crypto itself; the token is also just a blob to the host.

So, in practical terms, the host would want to POST/PUT some information in JSON format (it be valuable for it to be in JWT format) that constitutes the referral info, and the AM could encrypt it directly for itself (the "stateless" choice), and hand it back. The host turns around and gives it to the requester, which carries it back to the AM endpoint it was told to use. Call this "host and requester are both dumb mules"! The OpenID Artifact Binding spec has some PHP libraries that implement the pre-final versions of the JWT, signing, and encryption specs for doing all this. The host, if it wants, could sign the referral info.

Trusted claims: review and discuss proposal materials

What if we were to say that "claims hosts" (the specialized kind of host that appears in the tclaims pictures, that are likely IdPs themselves) had to conform to a profiled portion of the OpenID AB spec? That spec doesn't impose any constraint on the types of claims you could be conveying, which is good because UMA doesn't want to have a dependency on OpenID identifiers or attributes specifically. But it does assume that an SSO session is being created along with conveying the claims. UMA, on the other hand, typically is trying to preserve the option of "user-absent" sharing. It should be possible for the subject of the claims to set up policy ahead of time that allows for claims to be shared without their further intervention; this is an UMA design principle. But this would require some fancy footwork around how the AM knows it's okay to release the claims.

Domenico's latest wireframes in the enterprise-class scenario assume the user is present, which makes things simpler. Are we willing to make this simplifying assumption for our purposes in Step 2? Or is it worthwhile using something like the OAuth assertion profile to allow for truly user-absent cases?

Next Meetings

  • WG telecon on Thursday, 20 Jan 2011, at 9-10:30am PT (time chart) – regrets from Eve; Maciej M. will chair
  • WG telecon on Thursday, 27 Jan 2011, at 9-10:30am PT (time chart)