As of 22 Aug 2011, quorum is 6 of 10.
Non-voting participants:
Regrets:
Quorum was not reached.
Deferred due to lack of quorum.
The proposals likeliest to be accepted involve concrete deliverables and equity – either "sweat equity" or money coming from another source that can be matched. See the 2011 budget requests for examples.
Some ideas:
Eric Sachs will substitute for Maciej in the UMA/OpenID Connect synergies slot in next week's OpenID Summit. Kirk and also Farhang Kassaei of eBay will be there "representin'" for UMA.
We have the basic logistics worked out. We don't yet have a smooth process for merging live versions of the XML source, but we're getting there.
Thomas has a question on how to implement the results of closed issue #3. He's supposed to add an rsid and policy redirect URI to the AM's response when a resource set is registered or changed. What's the purpose of the rsid in that case, since it's a response directly to registering/changing such a thing, so the host should already know it! We will assume the SMART project had a good reason for including rsid in the response, and will open a new issue to ask if it's superfluous.
We agreed that the error discussions in Section 2.4 should be "factored out" to provide method-specific and API-generic errors and to point to Section 4.2 rather than repeating lots of long error examples in Section 2.4. Thomas will follow up on this without having a formal issue open on it.
Kirk will keep an eye out next week for new issues that we should open along these lines. Right now, we think issues #2 and #20 are at least somewhat related. We'll look for incompatibilities, terminology confusion, and overlaps particularly.
Regarding issue #2, we believe that the way OpenID Connect is shaping up, we may very well be able to use it as a mandatory-to-implement (or even perhaps the only?) claims language embedded in the UMA claims-requested messaging protocol that covers both a basic set of self-asserted and third-party-asserted (trusted) claims, and also an extension mechanism for arbitrary other (e.g. industry-specific) claims.
Regarding issue #20, this is yet a different way there may be UMA/OpenID Connect synergy. OpenID Connect is trying to solve for some discovery use cases. UMA (e.g., the hData use case) would need a "protected" discovery service, not an open one, but otherwise we think it has very similar needs. How can aspects of the two be combined or reused for best efficiency and modularity? Keep in mind that UMA solves for third-party requesters and absent authorizing users for arbitrary protected resources, while OpenID Connect solves for present authorizing users trying to start a session and protected claims specifically.
Issue #6 is a variant of issue #5. We think this can be closed with no action because you have to deliberately supply the ETag of the resource set you want to update. This is already in the spec. Under what circumstances would the host have an entirely wrong ETag and it doesn't match? Maybe the ETag in its database got corrupted and this is where asking the AM to list all the resource sets it knows about can be helpful. Let's consider #6 closed.
Issues #4 and #7 deferred.
See above; discussed but far from being closed.