UMA telecon 2010-04-22

Date and Time

Day: Thursday, 22 Apr 2010
Time: 9:00am-10:30am PST | 12:00-1:30pm EST | 16:00-17:30 UTC (time chart)
Dial-In:
- Skype: +9900827042954214
- US: +1-201-793-9022 | Room Code: 295-4214 (other local country numbers available on request)

Agenda

Roll call
Approve minutes of 2010-04-15 meeting
Action item review
Call for participation in Concordia authz workshop (draft abstract) at Burton Catalyst in July
User experience/user story review
Protocol spec review/focus team report/implementation status
AOB

Attendees

As of 7 Apr 2010, quorum is 6 of 11.

Adams, Trent
Akram, Hasan
Armstrong, Brian
Bryan, Paul
Catalano, Domenico
Fletcher, George
Holodnik, Tom
Machulak, Maciej
Maler, Eve
Moren, Lukasz

Non-voting participant:

Mark Lizar
Jeff Stollman
Louis Monvoison

Minutes

New AI summary

2010-04-22-1

Eve

Open

Eve to follow up on Catalyst workshop interest and find out participation fees.

Roll call

Quorum was reached.

Approve minutes of 2010-04-15 meeting

Minutes of 2010-04-15 meeting APPROVED.

Action item review

2010-03-10-2 Maciej Open Do next round of spec editing. We'll target spec edits to catch up to implementations by the demonstration timeframe.
2010-04-08-1 Eve Open Turn Paul's "claims 2.0" proposal into a draft spec. Pending; keep open until real spec doc is created.
2010-04-15-1 Eve Open Reach out to legal eagles to get review of new technical report.
2010-04-15-2 Domenico, Maciej Open Share user stories and wireframes on the WG list so that we can coordinate these activities in email. Now closed.

Call for participation in Concordia authz workshop (draft abstract) at Burton Catalyst in July

The following people are tentatively interested: Eve, TomH, Maciej. There are fees for having speaking slots and pods. Note that the IETF78 meeting will be held the same week in the Netherlands.

User experience review

New wireframes are here.

We discussed the wireframes. We anticipate that the authorizing user will never see the word "claims", but rather something functional. Jeff suggests "Use Restrictions" instead of "Contract Type", because many (most? all?) underlying claims exchange scenarios imply the forging of a contract.

Eve mentioned that as it stands, the "Resource link to share" item under Default Sharing Policy seems like it duplicates the big Share button the right. However, we have discussed the notion of lightweight security in the form of "private URLs", and this could be a nice clean way to generate a private URL per resource+policy pair. Alternatively or in addition, there could be a private URL per specific requester listed in a policy. George notes that the AM can only make a new URL in a domain it controls (such that the private URL is kind of a URL shortener at best); only the host could make a private URL that really lets the requester in immediately.

The feed management item might want to have a default of "indefinitely", and also possibly something that equates to "one-time" (though GET semantics make it impossible to judge that it was only accessed one time). Something like "for an hour" or "for a day" might be useful.

The "ask me for consent first" and "notify me about data access" options might use a phone number or registered mobile app or email address that has been configured into the User Profile tab.

Eve advocates that we keep things very simple for how to configure resources and policies into baskets: She imagines that users will likely want all resources in a basket to inherit whatever the basket's policy is. She has been conceiving of baskets as a special category of resource that is hosted by a host that has a special tight relationship with the AM.

She guesses that the whole topic of baskets doesn't really have protocol implications per se, but does have some fairly deep application implementations. Or does it have protocol implications? George asks if a requester has already proved that it has a right to get to the basket, can it proceed to each of the linked resources (on whatever hosts) and get immediate access with the token it was already given? Paul believes that the procedure for having the requester prove itself at each host should remain in place, but that it's possible some of these interactions can, on a per-host basis, be optimized through scope-parameter tricks when the AM issues the first token involving each host.

George wonders if this is missing an opportunity for truly intuitive and useful optimization on the requester's part when accessing all the things in a basket. Should it be possible for the requester to approach each host/protected resource in a basket with some kind of intermediate token saying that it's asking for access as part of a "basket request", so that it doesn't have to re-qualify over and over at the AM, by (e.g.) presenting the same set of claims? Then again, if inheritance works such that the "strongest" policy (according to whose definition??) is inherited by everything in the basket, that could be valuable.

User story review

User stories from Newcastle project are here.

Maciej walked through the user stories most related to composing policies, as they are most closely related to the wireframes just presented. User story #21 involves associating claims with an existing policy. Eve comments that "claims" as used in the stories may want to be worded more like "restrictions" (see the discussion above about "Contract Type"). Maciej notes that the intent is for the user to be able to select desired constraints.

George observes that common ways of restricting access today include drop-downs like "no one", "friends", "everyone", etc. We discussed the terms negotiation portion of the Scenarios document that categorizes demands into promises and statements of fact, and further into requesting-party identification (a kind of statement of fact) etc.

The imlementation plan at Newcastle is to let users choose policies that get turned into constraints (uses the claims-required flow) and rules (the AM can decide unilaterally). For example, a policy on a resource could have a set of allowed requesters (requires claims) and possibly their allowed methods of access (essentially unilateral).

Maciej will bubble up further high-priority questions to the list and on future telecons, and asks for comments on the already-distributed stories to be sent to the list ASAP.

Claims 2.0 proposal

New claims 2.0 proposal is here.

We discussed the templates and the two proposed claims. Paul suggested that maybe an issuer shouldn't be provided at all unless it's signed, or that it should explicitly say NULL. Eve points out the "self-asserted requesting party label" use cases in the Scenarios document, and feels that this is useful. Paul suggests that this should be an additional claim, called ...requestingpartyname or something. And George fleshes out the picture by suggesting that some policies might want to restrict access to real human beings, with a demand that the person's real-life identifier be provided.

George mentions that some of the XRD folks have been interested in a JSON form thereof, and Scott Cantor found something called JSONML that can turn XML into JSON, though it's not very pretty. It's not clear that we are interested in expressing claims as XRD (NTTAWWT, but we may not be motivated to use it ourselves).

Next Meeting: UMA telecon 2010-04-29

Day: Thursday, 29 Apr 2010
Time: 9:00am-10:30am PST | 12:00-1:30pm EST | 16:00-17:30 UTC (time chart)
Dial-In:
- Skype: +9900827042954214
- US: +1-201-793-9022 | Room Code: 295-4214 (other local country numbers available on request)

Browser not supported