As of 6 Jan 2011 (pre-meeting), quorum is 8 of 15.
Non-voting:
Regrets:
Quorum was reached.
Eve regrets for next week; Maciej M. will chair.
Minutes of 2011-01-06 meeting APPROVED.
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:
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.
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?