Quorum was reached.
Minutes of 2012-05-31 and 2012-06-07 meetings APPROVED.
Thomas is available to serve as chair pro tem next week. We will cancel the July 5 call because of the nearby US holiday.
Alam reports that Fraunhofer is getting close to open-sourcing its implementation. It's Java-based. They have solved for three use cases. Mario's demo from the Kantara/EIC Summit meeting is available on YouTube.
Newcastle University is planning to deploy SMART AM in the fall. We've heard that the SMART implementation has hooks that would enable it to function as a test suite, but don't know the status.
The OSIS site has a live namespaced area for UMA1 now. In our ad hoc meeting, we started to brainstorm how to fill out the features, feature tests, participants, and solutions. Lukasz, Jacek, and Alam have OpenIDs, so we should be set for now. Trey needs a local account and will ping Pam Dingle about this.
Discussing the "AM provides config data" feature example: In SCIM, they're going feature by feature and creating a unit test for each thing. An integration test usually consists of a bunch of unit tests. There's a chicken-and-egg problem. It seems not all that valuable to have hundreds of unit tests. Our primary goal with this interop activity is to assess, with some certainty, whether implementations that _claim_ conformance likely are conforming. (We just want conformance self-assessments at this point to encourage interop, not to govern legally enforceable claims of conformance.) So we'll have at least 1:1 feature/feature test mappings, and possibly 1:many, but not that many.
Note that RPT issuance and permission-granting are two separate endpoints again, with a 401 leading to the first and a 403 leading to the second.
Domenico proposed a way of solving federated discovery involving multiple AMs. George noted that the discussion on the OAuth list around "AM config data" vs. AS linked data is continuing. Discovery is still a "user-centric" capability, in the way we're talking about it, since it's about requesters finding "George's photos". In many cases, the AM that a user chooses to use could also be a host of discovery information, but we likely don't want to require it or mandate an architecture that puts the two together. Looking at the health community, we anticipate there being a small number of AMs. A user will have to pick among AMs that are supported by/acceptable to the hosts in that sector. This means that discovery has to be separated from the AM function. We achieved consensus on this point.
However, AM config data and other similar things (OpenID Connect config data, SAML metadata, etc.) is more like machine discovery; it's totally individual-independent. Hostmeta dictates XRD and link relations, which we've gone away from. We need to track this as an issue because some functionality may get sedimented into normal OAuth practice that we should try and follow for better interop.
For discovering authorizing-user-specific resources, would the resource set registration process present a chance to define some extension properties that would give the AM permission to serve as a host of discovery data about that resource set, and teach the AM what it needs to know? Then the discovery interface presented by the AM could be standardized as part of that extension, possibly leveraging lessons learned from the OpenID Connect distributed claims model (while likely not using it directly, since claims are different from arbitrary web resources). Should the host mint tokens that it can supply to the discovery service, and then validate itself when it comes back, to avoid too many user bounces?
As of 22 May 2012, quorum is 6 of 10.
Non-voting participants: