UMA telecon 2014-06-12

Date and Time

Focus meeting Thu Jun 12 8:30-10am PT (time chart)
- Voice: Skype: +99051000000481 or US +1-805-309-2350 (international dial-in lines), room code 178-2540#
- Screen sharing: http://join.me/findthomas

Agenda

Webinar status:
- Date: June 19, 8-9am PT
- Theme: UMA, OpenID Connect, and personal data stores ("You can't spell human without UMA" )
- Key participants: Maciej/Cloud Identity, Thomas/Justin?/MIT-KIT, Dazza/MIT, and Nat so far
- Hashtag: #UMApcloud
- Sponsorship: MIT
- Registration page: http://bit.ly/umapcloud
Refreshing the Resource Set Registration spec
Considering an Open Member Ballot for "UMA v1"
RS config data: any further discussion based on George and Mike input after last week?
URL pattern-matching: any further discussion based on Mike input after last week?
Multi-AS policy sourcing (Gluu)
Claim profiling work (Cloud Identity)
AOB

Minutes

Latest momentum

We've been hearing from the Department of Internal Affairs around eID use cases, and also from a large media company, all with interest. IoT interest continues high. Prabath is writing a book in which there's an UMA chapter. And what about the UMA implications of "solar FREAKIN' roadways"? Sal has long experience in the area of smart transportation and "roadside communication", and supports the notion. We've already seen hacks of connected cars; there's a lot of room for authorization models along these lines.

Maciej hosted a session on UMA at Newcastle University yesterday, with Domenico and Eve focusing on LMPs and enterprise use cases, respectively. The turnout and interest were good. Research and also operations folks attended. We took video of the event, so we hope to publish this.

Webinar status

Date: June 19, 8-9am PT
Theme: UMA, OpenID Connect, and personal data stores ("You can't spell human without UMA" )
Key participants: Maciej/Cloud Identity, Thomas/Justin?/MIT-KIT, Dazza/MIT, and Nat so far
Hashtag: #UMApcloud
Sponsorship: MIT
Registration page: http://bit.ly/umapcloud

Webinar agenda:

Problem space: Domenico and Eve
UMA 101: Eve
PDS to pcloud to LMP: Domenico
Involved parties and use cases, and MIT-KIT's interest: Thomas
1. Include a brief mention of the healthcare version of the challenge
The role of OIDC in claims-gathering and login to the various systems: Maciej
Next steps

AI: Thomas: Reserve the WebEx for 10:30am-noon ET and provide the information to Joni.

AI: Eve: Create webinar slides framework and ask for contributions into it.

AI: Everyone: If you want to attend the webinar, you have to register! Go to bit.ly/umapcloud to register.

In healthcare, Adrian notes that the UMA/OIDC relationship is known as the "multiple portals problem" – it's not just about logging in, but also about collecting consent at all of these places.

Refreshing the Resource Set Registration spec

Thomas did a keep-alive draft. Let's do more substantive updates soon. It appears people are starting to finally need it.

Eve pointed to apisjson.org and apis.io; this is relevant to George's analysis of Swagger, which the APIs.json folks think is insufficient for (presumably) OAuth scopes. RSR is about UMA scopes, of course. Sal has a particular interest in this.

Potential work items for the RSR spec:

Fix typos like all the spec citations
Possibly mention APIs.json, Swagger, WADL, RAML, etc.
Open issues around RSR – if you came across issues and haven't reported them, now's the time!

Considering an Open Member Ballot for "UMA v1"

Eve floats the idea of doing a Kantara All Member Ballot for at least the Core spec. Sal and Mark speak in favor. Let's fully consider this and be ready to possibly take a vote by the all-hands meeting on June 26.

AI: Eve: Send a message to the group proposing the All Member Ballot idea.

RS config data: any further discussion based on George and Mike input after last week?

(This is directly related to the RSR conversation above.)

Sal is working on common SNMP metadata for physical door-opening. Eve notes that every value-add API in the world may have its own unique metadata. What would be useful to put in that metadata/config data, for client discovery purposes? SNMP (or other existing) metadata could be scraped and presented in something like APIs.json. As far as resource sets and scopes go, if the existence of the resources is not a secret, then you could "declare" the resources in such config data. But typically you'd expect the existence of the resource to be protected. So maybe the RS would declare just resource set types (and their associated scopes), of which the actual resource sets as instances of the types could be registered with the AS. This sounds like server or endpoint automation!

URL pattern-matching: any further discussion based on Mike input after last week?

Deferred.

Multi-AS policy sourcing (Gluu)

Deferred.

Claim profiling work (Cloud Identity)

The key changes we need to the spec are filling out what it would look like to push an ID token (vs. just claims in the clear), and talking about pushing vs. "claims conveyor".

AI: Domenico: Try out a graphic that illustrates the redirect vs. push flows, focusing on the difference in the clients vs. the difference in what the AS does.

Attendees

Eve
Mark
Adrian
Jin
Sal
Maciej
Thomas
Debbie
Abhi
Domenico

Next Meetings

Webinar Thu Jun 19 8-9am (time chart) followed by focus meeting 9-10am PT (time chart)
All-hands meeting Thu Jun 26 8:30-10am PT (time chart)

Browser not supported