UMA telecon 2010-11-11
- Former user (Deleted)
UMA telecon 2010-11-11
Date and Time
- WG telecon on Thursday, 11 Nov 2010, at 9-10:30am PT (time chart)
- Skype line "C": +9900827042954214
- US: +1-201-793-9022 | Room Code: 295-4214
Agenda
- Roll call
- Approve minutes of 2010-10-28 and 2010-11-01 meetings
- Action item review
- Brief updates from the wider UMA world
- Review and discuss progress from last F2F
- Review revised resource/scope registration proposal with RESTful interface
- Make conclusions about issues raised at the end of the F2F (see notes)
- Capture any new user stories being discussed
- Line up next set of spec issue priorities
- AOB
Attendees
- Trent Adams
- Domenico Catalano
- Sal D'Agostino
- George Fletcher
- Maciej Machulak
- Lukasz Moren
- Paul Bryan
Non-voting participants:
- Alam Mohammed
- Jeff Stollman
- Anna Ticktin (staff)
Regrets:
- Christian Scholz
- Eve Maler
Minutes
Roll call
Quorum was met (late in the meeting).
Approve minutes of 2010-10-28 and 2010-11-01 meetings
Deferred.
Action item review
- 2010-11-01-1 Alan Open Write up backup service/copy service use case, with reference to requester delegate scenario. Now closed.
Review revised resource/scope registration proposal with RESTful interface
Discussion is around resource registration and the recent proposal from Maciej and Lukasz.
We discuss issues raised at the UMA F2F meeting where the group would identify 3 problems with regards to resource, namely Problem A, Problem B and Problem C: Problem A is when the user wants to register resources when being at a Host - these resources are registered at the AM and this is where the policy gets applied to these resources. We also considered the possibility that the user might want to remain at the host while associating a policy with a resource for lowest possible UX friction, which we called "problem B", and to cancel protection for a particular resource while visiting the AM, which we called "problem C".
Maciej then shows the new format of the message that is sent between the host and the authorization manager (JSON encoded instead of url-encoded as in the original proposal). Maciej says that a new version of the proposal should be submitted to the group. (Now done.)
We discuss how the requester learns the names of tags/scopes that are associated with the resource. The AM only knows these names and not actual resources.
Resources can belong to different groups. The policy applies criteria to this resources.
Requester goes to the AM to get authorized and provides the resource that it wishes to access and the group that the resource belongs to. This is all based on the information that has been submitted from the host to the requester in the first attempt to access a resource (i.e. when the requester would not yet have a token to access this resource).
The Host informs the Requester about the AM to which the requester needs to talk to. The host needs to know that based on the resource (i.e. when multiple users use the same Host and different AMs then the host needs to know which AM it should talk to).
The flow for the user is also discussed - i.e. should we have a flow where a user is redirected to the AM to define policies for resources that are meant to be policy protected or could the host simply register a resource and some sort of a default policy would be associated with a resource (no redirection would occur). Maciej and Lukasz think that the step of redirection is necessary and it might be meaningless for the user to see simply see that a resource is now “Protected” (but how protected?). George gives an example, that by resigning from such a redirection we would allow for registering groups of resources easily (the user would not be redirected to the AM after the host registeres a single resource). Maciej thinks this might be solved differently when a single registration request is issued by the host to the AM.
There is a question then - should we specify only the Host <-> AM request/reply protocol and define the user redirection step as optional?
Resource identifiers are then discussed - URIs vs arbitrary strings. The AM only needs to know identifiers of resources - there’s no way the AM will know how resources are organized at the Host.
Next Meetings
- WG telecon on Thursday, 18 Nov 2010, at 9-10:30am PT (time chart)