As of 7 Apr 2010, quorum is 6 of 11.
Non-voting participants:
Regrets:
2010-04-29-1 |
Paul |
Open |
Revise Claims 2.0 and SAAC specs |
To be done by May 6. |
Quorum was not reached.
Deferred due to lack of quorum.
Other ideas for AIs and activities going on:
Gerry is getting involved in the Authorization workshop for XACML reasons, and potentially offers some assistance in getting UMA some exposure there. We'll treat the end of next week as our deadline for figuring this all out.
Eve, Maciej, Lukasz, Gerry, and Domenico will be at next Tuesday's workshop. We think roughly 20 people will be signed up. Gerry suggests finding out the interests and use cases of the people who attend; Eve will build this into the agenda.
We now have a defined core structure for claims, which has basic structure for things like issuer (but not subject, which is a flaw). And Eve has published a very early draft of Simple Access Authorization Claims, which needs a lot of work.
The really tricky part is how to match the subject to the claim, and this is currently unsolved in the drafts. Getting subject identification right in the case where the policy demands that only a specific (list of) unique identifier(s) can get access is the tough part.
Paul intends to change the spec in the following fashion:
There's always an issuer, and there's always a subject. A claim-requested could demand subject of "*" (any), or could demand a specific subject string (or list of them), such as "bob@gmail.com". If it's a concrete value, then the part of the UMA protocol in which the AM requests claims of the requester may (in a naive situation) have n steps in it, where the AM, having gotten a claim with the right string back, may issue a challenge and ask for it to be signed. Or the AM can in the first/only request-wave include a nonce (which functions as an AM-issued identifier for this subject).
Eve observes that with the advent of webfinger, hostmeta, and the growing LRDD ecosystem, we can start solving problems of "deep authentication" in the right way, vs. whitelisting tricks of old. Thus, Paul points out, solving problems like Gerry's example of Earthlink.com now owning Mindspring.com could be solved with some kind of (presumably brittle) whitelisting, or it could be solved by Earthlink.com standing up some dynamically discoverable hostmeta at Mindspring.com.
Maciej and Lukasz are likely to start with the really simple case of claims, such as the Requesting Party Policy claim that's been proposed. This one doesn't require as many unique identifier tricks.
Currently, the Claims 2.0 spec proposes using the signing method proposed by the CouchDB folks. It doesn't have a public key discovery method, but we've added it. The primary alternate candidate is the Magic Signature approach, which was defined in the course of specifying Salmon. Magic Signature base64-encodes everything to get around normalization issues, but it makes the payload look opaque to the casual observer.
In email, George had expressed a preference for Magic Signature. The CouchDB method could be made normalizable, but it turns out it would have to forbid the use of certain JSON corner cases. In the WRAP and OAuth world, Eve observes that the Magic Signature approach has generally been "well tolerated", though a few comments came in about how it could be improved along the lines of SAML's SimpleSign spec. (The CouchDB approach was not mooted there.) We agree in principle to try the Magic Signature approach.
The big top-of-mind concern right now, other than claims, is the dynamic provisioning of client credentials to new hosts. We had decided that the hostmeta file could indicate a non-client-specific set of credentials that new hosts could use in approaching the AM in order to be introduced to it. Eve had earlier suggested to Maciej that since in OAuth 2.0 the client secret is optional, if the credentials are dynamically provisioned then perhaps only the client ID is needed. (He may provision both anyway.) There are also lots of cases where, in fact, the host and AM might have a static relationship and the AM previously sent the host all the credentials it needed without need of the hostmeta trick.