- Roll call
- Approve minutes of 2012-05-31 and 2012-06-07 meetings
- Meeting wrangling
- Need chair pro tem for June 21 meeting
- Cancel July 5 meeting due to US holiday the day before? (Eve regrets)
- Feature-test-fest results from previous day
- Spec/issues review
- Review dynamic client registration news
- Review new UMA core spec (link coming shortly)
- #20: Only discuss if we have new input related to OIC/Street Identity/etc.
- #50: Considering modularizing the AS/RS interop portion for wider non-UMA adoption
- #56: Standardized scope descriptions for well-known APIs?
- Look at other current issues
- "UMA for Enterprise" use case discussion
New AI summary
- Eve and Trey: By next Thursday, brainstorm features and corresponding feature tests against the spec. Eve will continue to work on Sec 1.5. She will also work on Sec 2. Trey will work on Sec 3.
- At least SMART and Fraunhofer teams: Create participant and solution entries in the OSIS wiki for themselves.
- Eve: Put Tom Brown, Trey, and other interested UMA and OAuth parties together, updating the Implementations page to reflect.
- Thomas: Editorial instructions: Enhance 3.1.1 to explain that this is a 401 and MUST contain the "am-uri" property, and revise to point to our own dyn-client-reg spec again instead of the OpenID Connect one.
- Eve: Add issue to track the AM config data/OAuth linked data issue that Bill Mills floated on the OAuth list.
- Thomas: Write up MIT Media Lab use case.
- Eve: Gather Kevin's input for new FAQ entries.
Quorum ?was reached.
Approve minutes of 2012-05-31 and 2012-06-07 meetings
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.
Feature-test-fest results from previous day
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.
New core spec rev 05a review
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.
Issue #20 discussion
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.
- Catalano, Domenico
- Drake, Trey
- Fletcher, George
- Hardjono, Thomas
- Maler, Eve
- Moren, Lukasz
- Szpot, Jacek
- WG telecon on Thursday, 21 June 2012, at 9am PT (time chart)
- WG telecon on Thursday, 28 June 2012, at 9am PT (time chart)