UMA telecon 2011-02-10
Date and Time
As of 8 Feb 2011, quorum is 8 of 15.
New AI summary
Quorum was reached.
Approve minutes of 2011-02-03 meeting
Deferred due to desire to review for a longer period.
Action item review
Sal, Eve, and Maciej M. will be at (most of) the RSA Kantara/IIW collab day next Monday. We'll try and hold an informal BOF while there.
We don't seem to have critical mass to hold a formal meeting, but Alam has offered to show an UMA-related demo during the Berlin meeting time. He and Dervla will work on scheduling the demo time, and Alam will share details of his planned demo with our list.
If anyone is interested in submitting a paper and wants help, please speak up.
Eve, possibly Susan, and likely Sal will be in attendance. It would be great to be in a position to show some new demos.
Ian Glazer blog post
UMA gets a mention. People may want to check it out and comment on the post or share thoughts on our WG list.
Kantara roadmap items
Discuss role of digital signatures
If we can push complexity to the AM by having it verify its own signatures on behalf of a host (though a back-channel call) as necessary, we achieve the benefits of signatures without necessarily burdening the host unduly. The proposal wording was:
"Don't preclude strong authentication through digital signatures, and leverage and adopt signatures as options if a reasonable measure of interoperability can be achieved."
Should it include something about standard signature solutions? E.g.:
"Don't preclude strong authentication through digital signatures, and leverage widely supported signature solutions as options if a reasonable measure of interoperability can be achieved."
The goal here is to promote developers not to roll their own implementations, but rather use existing libraries or other open-source/platform solutions.
Motion: Approve design principle 13 with the title "Digital Signatures" and the text "Don't preclude strong authentication through digital signatures, and leverage widely supported signature solutions as options if a reasonable measure of interoperability can be achieved." Passed by unanimous consent.
Step 3 host-AM communication options
Paul's conception is that the host will treat the requester's access token only as authenticating the requester, and that it will always ask for authorization directly from the AM. An authorization decision that the AM gives the host can be cached by the host as an optimization strategy. But let's say that the requester had previously (in step 2) given claims to the AM, which gave it authorization rights at the time – but that the claims are very time-sensitive. If the requester finally gets around to asking for access at the host but its authorization (which only the AM knows) has expired, then the host will find out from the AM that the requester is not authorized and will have to send it back to the AM.
There are three choices for what the step 3 host-AM token validation communication looks like:
The current OAuth deployments have very small "scope universes". Some UMA use cases do have small universes too, but other use cases (a professional photographer protecting thousands of photos in a fine-grained manner) may involve many scopes that might have to be transmitted in a single token.
We gained consensus that the hybrid solution is a good place to start and allows us to grow as the underlying technologies mature. Thus, Paul's existing action item merges with Christian's completed one, and Paul will sketch the solution directly in the 'pad.
Is this site useful to you? Please share it!
| | More
Pages in this Space: