UMA telecon 2016-02-18

Date and Time

Thu Feb 18, 9-10am PT
- Voice: Skype: +99051000000481 or US +1-805-309-2350 (international dial-in lines), room code 178-2540#
- Screen sharing: http://join.me/findthomas - NOTE: IGNORE the join.me dial-in line shown here in favor of the dial-in info above (Kantara "line C" and the Skype line)
- UMA calendar: http://kantara.atlassian.net/wiki/display/uma/Calendar

Agenda

Roll call
Approve minutes of UMA telecon 2016-01-07
Review the recommendations for issue #239 and decide and execute on next actions
- Proposal: Regardless of other decisions, develop a non-normative analysis of the attack and mitigations; revise as appropriate depending on other decisions taken (Sarah has this AI already)
- Proposal: Develop an extension specification, Enhanced Claims-Gathering Security Extension, to require cycling of the permission ticket when using the claims-gathering extension
- For discussion: Consider also handling issue #167 in this extension if it has a security rationale
- For discussion (thanks Andi for these two new bullets!): Consider updating the UMA Core spec in some way to point non-normatively to the extension spec, and/or mention it from the UIG
- For discussion (possibly at a later juncture): Consider if/when/how to fold the extension into a future UMA version (likely to be captured as a GitHub issue)
- For meta-discussion: What to do right now, as soon as we decide all this?
Kicking off #wideeco discussion: inputs from Eve/James and others
Making plans for IIW
- Thoughts on tasks we can accomplish there: CIS-flavored, legal-flavored, and interop-flavored efforts?
- Who will definitely be there? Whose plans are contingent on the WG's plans?
Charter-bashing (thanks Adrian for kicking this off!)
AOB

Minutes

Roll call

Quorum was reached.

Approve minutes

Minutes of UMA telecon 2016-01-07 approved.

Issue #239

Proposal: Regardless of other decisions, develop a non-normative analysis of the attack and mitigations; revise as appropriate depending on other decisions taken (Sarah has this AI already)

Proposal accepted.

Proposal: Develop an extension specification, Enhanced Claims-Gathering Security Extension, to require cycling of the permission ticket when using the claims-gathering extension

Sal and Eve just discussed in email whether a stronger authentication mitigation would work. Session fixation happens after victim authentication, so it wouldn't help.

Robert mentioned to Eve offline that Wikipedia has some comments on session fixation that might be useful. Eve believes that since the permission ticket gets passed in UMA JSON messages, the countermeasures there may not apply, but we could look (for purposes of the non-normative analysis if ultimately nothing else).

For discussion: Consider also handling issue #167 in this extension if it has a security rationale

If the AS uses the flexibility to give a new endpoint, then there's the danger of giving an attacker new information outside of the discovery document that it didn't have before, which is a degradation of security. If the AS doesn't avail itself of the flexibility, then it doesn't seem to add anything. In any case, we're not thinking of a security rationale for adding this feature to the extension. In any case, it sounds like taking up #167 as part of the extension work doesn't meet our "#security use case bucket" goals, so we'll defer that till such time as we take up "#simplify use case bucket" work.

Consensus: We want to write and publish the extension specification.

For discussion (thanks Andi for these two new bullets!): Consider updating the UMA Core spec in some way to point non-normatively to the extension spec, and/or mention it from the UIG
For discussion (possibly at a later juncture): Consider if/when/how to fold the extension into a future UMA version (likely to be captured as a GitHub issue)

The WG itself can self-approve a technical specification, and the LC can approve that group output. (Are these "WG Reports"? Eve will check with the LC.) In other words, this could remain at a level sort of equivalent to an IETF I-D and not progress to an "RFC" level before it eventually gets absorbed into a later version of the UMA Core spec. We do want to recommend that everyone using the claims-gathering endpoint use this approach, but it all depends on the timing of any new UMA "V.next" version. We basically need to defer the decision about its "track" until we execute on the rest of our roadmap.

AI: Eve, Domenico, Maciej: Write the extension spec.

Can we publish these by next Thursday? Let's give the old college try. We want to publish and publicize the draft docs at the same time.

Wide ecosystem challenges

Eve presented a set of high-level statements that describe the dual nature of the challenges. Eve/James and Maciej will share some material on the challenges.

John observes that it's an ouroboros – a snake eating its own tail (or as Eve likes to call it, the bubble under the wallpaper that you can move but you can't remove).

Some discussion arose about different solutions, e.g.:

UMA-protected user claims endpoint ("UserInfo")
Agreed-on central authority (e.g. hospital) serving as a claims endpoint/AS (?) – akin to the question that has arisen over the last decade-plus about "who's the IdP"

The group agreed to collect all the potential solutions "without fear or favor" and then analyzes how well they solve the challenges.

Attendees

As of 16 Feb 2016, quorum is 6 of 10. (François, Domenico, Kathleen, Sal, Thomas, Andi, Robert, Maciej, Eve, Mike)

Eve
Kathleen
François
Domenico
Sal
Mike
Maciej

Non-voting participants:

John W
Sarah
Adrian
George
Scott
Mark

Browser not supported