UMA telecon 2014-02-27

Date and Time

All-hands meeting Thu Feb 27 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

Roll call
Core 09* and claim profile review
Other interop planning
AOB

Minutes

Roll call

Quorum was not reached. We will make next week's meeting an all-hands meeting and seek quorum to approve the latest specs.

Zhanna works at MIT-KIT. She's working on OIDC and UMA efforts. Thomas notes that MIT-KIT is running a healthcare workshop in March; info is here. The MITREid open-source code is now owned by MIT.

Spec review

We discussed Domenico's concepts document for claim profiling. We think that our mention, last week, of the client pushing X.509 certs to the AS really needs to qualify that with "attribute certificate". A regular certificate for authentication is not the moral equivalent of an OIDC ID token, in that it really doesn't give any useful claims – even in "privileged nameID attribute" form. If OIDC had an "extended feature" to take in an authentication certificate and return user claims, it could be a cool protocol to solve this problem! In the CommonWell pilot, authentication is through the client certificate, so Jin is thinking about the X.509 connection for that use case.

Does it make sense to consider a hybrid of the push and pull approach? Apparently not, for the moment.

Maciej's hybrid approach of an ID token plus custom claims could be valuable in a closed environment where the specific claims have been negotiated out of band in a closed environment. Choosing this profile would essentially mean "The semantics of the claims beyond the ID token are not exposed to the UMA layer."

Jin asks: Does OAuth language speak to the question of naming all these concepts? (Push/pull, "client sends RqP" vs. "client sends claims", AS as claim receiver vs. AS as claim connector, etc.) Do these capabilities get sequestered specifically in public vs. confidential clients? It appears there's no reason a web app couldn't do both patterns. A native client might find it easier to deliver claims, but it still isn't barred from redirecting the RqP. So that's not the distinction.

How about this? If the AS advertises (in config data and/or need_claims) that it wants back claims of a certain type, the client needs to be a "claims-aware client". If the AS advertises that it needs the client to redirect the RqP over, the client needs to be a "redirecting client".

We'll have a spec editing session this Sunday to work on the merging together of all the claim profiling streams.

Attendees

As of 18 February 2014 (pre-meeting), quorum is 7 of 13.

Eve
Thomas
Domenico
Maciej
Jin
Zhanna Tsitkov

Regrets:

Mark
Adrian

Next Meetings

All-hands meeting Thu Mar 6 8:30-10am PT (time chart)
No meeting Thu Mar 13 8:30-10am PT (time chart) - Eve regrets
Focus meeting Thu Mar 20 8:30-10am PT (time chart) - N.B.: US has changed clocks by now - "summertime skew"
Webinar Thu Mar 20 8-9am PT (time chart) followed by focus meeting 9-10am PT (time chart) - N.B.: US has changed clocks by now - "summertime skew"

Browser not supported