E-mail
UMA telecon 2012-06-14Date and Time
Agenda
MinutesNew AI summary
Roll callQuorum was reached. Approve minutes of 2012-05-31 and 2012-06-07 meetingsMinutes of 2012-05-31 and 2012-06-07 meetings APPROVED. Meeting wranglingThomas is available to serve as chair pro tem next week. We will cancel the July 5 call because of the nearby US holiday. Implementation news 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. Feature-test-fest results from previous dayThe 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 reviewNote 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 discussionDomenico 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. 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? AttendeesAs of 22 May 2012, quorum is 6 of 10.
Non-voting participants:
Next Meetings
|
Bookmarks
Is this site useful to you? Please share it! Pages in this Space:
|
Labels