Minutes for December 12th call

Minutes for the meeting of the Electronic Identity Credential Trust Elevation Methods (Trust Elevation) Technical Committee

December 12, 2013.

1. Call to Order and Welcome.

2. Roll Call

Attending (please notify me if you attended the meeting but are not on the list below)

Abbie Barbir, Bank of America

Anil Saldhana, Red Hat

Bob Sunday

Brendan Peter, CA

Carl Mattocks, Bofa

Cathy Tilton, Daon

Charline Duccans, DHS

Duane DeCouteau

Colin Wallis, New Zealand Government - y

Dale Rickards, Verizon Business

David Brossard, Axiomatics

Dazza Greenwood

Debbie Bucci, NIH

Deborah Steckroth, RouteOne LLC

Detlef Huehnlein, Federal Office for Information

Diana Proud-Madruga - y

Diego Matute, Centrify

Don Thibeau, Open Identity Exchange - y

Doron Cohen, SafeNet

Doron Grinstein, BiTKOO

Gershon Janssen - y

Ivonne Thomas, Hasso Plattner Institute

Jaap Kuipers, Amsterdam

James Clark – Oasis

Jeff Broburg, CA

John Bradley

John "Mike" Davis, Veteran's Affairs

John Walsh, Sypris Electronics

Jonas Hogberg

Julian Hamersley, Adv Micro Devices

Kevin Mangold, NIST

Lucy Lynch ISOC

Marcus Streets, Thales e-Security

Marty Schleiff, The Boeing Company

Mary Ruddy, Identity Commons - y

Massimiliano Masi, Tiani "Spirit" GmbH

Mike Harrop

Mohammad Jafari, ESC

Peter Alterman, SAFE-BioPharma - y

Rainer Hoerbe -

Rebecca Nielsen, Booz Allen Hamilton

Rich Furr

Ronald Perez, Advanced Micro Devices

Scott Fitch Lockeed Martin

Shaheen Abdul Jabbar, JPMorgan Chase Bank, N.A. - y

Shahrokh Shahidzadeh (Intel Corp

Suzanne Gonzales-Webb, VA - y

Tony Rutkowski

Tony Nadlin

Thomas Hardjono, M.I.T.

William Barnhill, Booz Allen Hamilton

Adrianne James, VA

Patrick, Axiomatics

Steve Olshansky - y

81 percent of the voting members were present at the meeting. We did have quorum.

2. Agenda review and approval

We used the following chat room for the call: http://webconf.soaphub.org/conf/room/trust-el chat room text is included at the end of the minutes.

The agenda was approved.

3. Approval of the Minutes

Mary asked for a motion to approve the minutes from the last meeting on November 14 and from the meeting on October 31.

Peter made a motion to approve these minutes.

Abbie seconded the motion.

There were no objections.

The minutes were approved.

4. Editors Update.

Steve reported that we all should have received notification of working draft 10 of deliverable3. We are going to make a couple motions to approve it.

Don made a motion: I move to have the TC approve Electronic Identity Credential Trust Elevation Framework Version 1.0 working draft 10 contained in https://www.oasis-open.org/committees/document.php?document_id=51661&wg_abbrev=trust-e as a Committee Specification and designate the docx version as authoritative.

Peter seconded the motion.

There were no objections.

The motion passed.

Don made a second motion: I move to have the Committee Specification Draft of Electronic Identity Credential Trust Elevation Framework Version 1.0 submitted to TC Administration for a 30 day public review.

Peter seconded the motion.

There were no objections.

The motion passed.

Steve said he will work with Chet to move it into 30 day review.

Mary thanked Steve.

5. Presentation from Eve Maler

Eve Maler gave us an UMA 101 slide presentation.

Eve explained the original UMA purpose was for individual people. It has grown to include enterprise use cases, labor intensive and oversharing. Second problem is OAuth. It can lead you to consent at runtime, it is contract of adhesion. Now high volumes [of data] are flowing that we may not know are flowing. She calls that “oblivious oversharing.” We do have real life examples of Alice to Bob sharing – usually thru a private URL. If you want to share sensitive data, that is not good enough. UMA has worked on solving all of these issues. The premise is to enable the possibility of a central digital footprint console. There is unification, it is more consistent. You can start sharing with people and others. It can be claims- based. When you need app by app trust circles, if you advertise the availability of a resource, you have given away the URL. You want to be able to advertise availability without letting everyone else in.

Eve continued, the architecture of UMA is expressed by the marvelous spiral. If you know OAuth, most of bubbles are recognizable. If this was OAuth some of the bubbles would be tightly bound. In OpenID Connect terms, it is helpful to keep separate. New part if Bob is part of the picture. Bob isn’t part of OAuth. Use cases: resource server can protect any kind of data or a random HTTP-based API. The verbs I want to share and I want to protect. A third use case is I want to control access, not be forced to consent over and over. This has extra importance for patient consent records – it is weak at runtime. But consent directives – mean pre authorization policy.

Key use cases are subscribing to friends’ personal cloud, sharing accessibility attributes (blind), student transcript sharing, IDESG healthcare sharing use case, and enterprise access management 2.0. Also, whatever it did for the browser it now needs to do for Mobil and API protection.

We are getting interest from Forgerock and Gluu. It is a profile of OAuth. OAuth has no concept of user party. UMA defines protection API and protection client. (PAT protection API token) – is a mash-up of resource registration API. In UMA scope is an interoperable edata structure, like an artifact pattern in SAML.

A second API is the authorization API. It is protected by an authorization API token AAT. We have a profile for this under Open ID Connect for something like a backwards OIDC. One needs just as much authentication of Bob as Alice. UMA says nothing about the format of policy; it can be XACML or procedural.

There are example key implementations. Gluu has an open source implementation. Forgerock is planning an implementation for an upcoming interop. Still have some outstanding implementations. MIT has been looking to do an implementation working with MITRE, wrote a binding obligation spec. Contractual axioms could be added to a trust framework. Would have AS, RS, resource servers and requesting parties. Authorizing Party is legal term for a resource owner. This has been influenced by Tom Smedinghoff, Dazza Greenwood and Scott David. What this might mean for trust elevation?

Suzanne asked, when you say work is underway on trust frameworks, do you mean a federal bridge, or what exactly.

Eve replied she doesn’t know of any third-parties looking to do this. They are still too identity focused. All the TF today speak SAML natively, but if asked to speak XACML, they would say what?

The noting of separating enforcement and decision making is something that UMA is doing. It can support an access federation. Today trust frameworks talk about joining a club and checking a list at the door. That means it has a coarse grained relationship. Specific obligations come at runtime, so at any one time, a subject may not have taken on all the obligations. If Alice goes to a website, she takes on the terms of service after she clicks on the terms of service. So all the token access... when the state changes, and change is detected by the PAT issued and received then things unroll. Same contractual terms could be bound to the tech. The innovation is finer-grained access by binding access to change in the universe.

Suzanne asked if consents have expiration dates.

Eve replied these are low level. If SAML, then the IDP, once it has issued an assertion about the user, warrants that it actually performed the claim for the duration of the time (2.2.3).

So if Bob self asserts his age, if the edifice fails because he is too young, then the edifice comes down on him and his guardian. Whole point is to have auditable things so you can sue the appropriate party. The Trust Frameworks are untested – there isn’t any case law. This is the party that makes the technical part of UMA trustworthy. One more thing, there is a third-party profile (by Gluu) for requesting party Trust-el. That requires an AAT to have been acquired on the basis of a specific LOA. It is an OpenID Connect extension. It uses Open ID Connect special sauce.

If the token is too weak, need to have Bob get a stronger token. What the profile achieves is to make sure it is not all based on a weak password. This is a practical positive vision of trust-el. This is what I was hoping to share. The rest was pre-amble.

Shaheen asked what happens when the access request scope changes.

Eve replied UMA has a little bit different relationship to scope. It uses a different flow than OAuth does. You can have requesting part go to RS first or to AS first. UMA currently specifies Bob goes to RS first so he needs provisioning or out-of-band discovery. The way UMA ends up granting a scope is by Bob trying to do it. So it is least privilege. The resource service dictates that there is read or write as a scope. If at first Bob is just reading, then later wants to write, he needs to be pumped thru again. So it is based on whatever scope the RS is willing to attach. The RS dictates the scope that is handed out each time.

Shaheen said that is exactly what we are trying to achieve.

Eve replied it has come up frequently. It is the Liberty scenario: Bob wants to find Alice’s calendar wherever it is and get the token. We have not standardized that flow yet. We don’t want to invent the discovery. This could be called a personal discovery service.

Colin asked if any security review had been done on it.

Eve replied a formal security review has not been done, but it is based on OAuth and also OpenID Connect. It references an existing threat model. Not that the issue of impersonation is a crucial one. The problem is it gains more oomph with doing Alice to Bob, than Alice to Alice. It leverages a single session. So we outlined some mitigations. Another issue concerns the implicit flow. Bob will have exposure to the token and could pass it along.

Colin commented so that is a meaty piece that we could hold on to.

Eve replied there is also a privacy considerations paper.

Suzanne asked if this is being done via Kantara.

Eve replied yes. Tinyurl/umawg gets you the home page of the wiki. The slides are on refresh Uma 1.1 Slideshare. There is also a version .2 of the demo video.

6. 4th deliverable discussion

We did not have time for this topic.

7. Adjourn

Mary adjourned the meeting as it was over time.

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

Mary Ruddy: Agenda

1. roll call

2. approve minutes

3. editor update

4. Presentation from Eve Maller

5. 4th deliverabe disvussion

6. Adjourn

anonymous morphed into Colin_NZ

Shaheen: -------------------------------------------------------

To join the online meeting (Now from mobile devices!)

-------------------------------------------------------

1. Go to https://jpmchase.webex.com/jpmchase/e.php?AT=WMI&EventID=276929562&RT=MiMxMQ%3D%3D

2. If requested, enter your name and email address.

3. If a password is required, enter the meeting password: (This meeting does not require a password.)

4. Click "Join".

5. Follow the instructions that appear on your screen.

> Motion:

> "I move to have the TC approve Electronic Identity Credential Trust Elevation Framework Version 1.0 working draft 10 contained in https://www.oasis-open.org/committees/document.php?document_id=51661&wg_abbrev=trust-e as a Committee Specification and designate the docx version as authoritative."

> Motion:

> "I move to have the Committee Specification Draft of Electronic Identity Credential Trust Elevation Framework Version 1.0 submitted to TC Administration for a 30 day public review."

trust-el message