OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

trust-el message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Notes From August 21

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

August 21, 2014.

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  - y

Anil Saldhana, Red Hat  

Bob Sunday

Brendan Peter, CA

Carl Mattocks, Bofa 

Cathy Tilton, Daon  - y 

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    

Doron Cohen, SafeNet

Doron Grinstein, BiTKOO

Gershon Janssen - y    

Ilene Bridges 

Ivonne Thomas, Hasso Plattner Institute

Jaap Kuipers, Amsterdam  

James Clark – Oasis

Jeff Broburg, CA

Jim Macabe (Kaiser) - y

John Bradley 

John "Mike" Davis, Veteran's Affairs 

John Walsh, Sypris Electronics

Jonas Hogberg

Julian Hamersley, Adv Micro Devices

Kevin Mangold, NIST  - y 

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 

Peter Jones -

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.  

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 

Andrew Nash - y


67 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


Abbie announced a new IBOBS TC. The first meeting will be within an ITU-T meeting. You need to join by September 2 [to be a voter at the first meeting]. It is a biometric based end-to-end-protocol. It provides identity attestation. The beauty of the protocol is that it enables higher entropy of biometrics. It builds on existing techniques.  It has its own built in security mechanisms.  An attacker would need to break the client and server at the same time to get access.


The agenda was approved.



3. Approval of the Minutes



Abbie made a motion to approve the minutes from June 26.

Gershon seconded.

There were no objections.

The minutes were approved.



4. Editor update


Abbie commented that it is summer. Many have been on holiday or traveling. We cancelled two of the meetings, so we haven’t made much progress. We did have one meeting and discussed end-to-end protocol.


Andrew emphasized we should see what the architecture of ecosystem should be and quickly.  We should talk with Eve.


Abbie replied we have Eve on the call. She is on the Webex.


Eve began. She wanted to take a moment to talk about UMA with respect to trust-el generally.  What she had seen of the original Trust-el materials, what was published, was information about the threats of elevation of privilege. She asked about the positive aspects of trust-el, which is what SSO is all about, for example JIT provisioning. So the positive vision is what UMA is about, it arranges for multiple loosely coupled parties to let the resource owner (Alice) selectively and maybe in real time grant entitlement to a third party (Bob) to have access based on Alice’s wishes and policies. The entitlement could be about identity data or anything. The notion of entitlements is key. It is about authorization to get entitlements. We call this the marvelous spiral. We want to elevate Alice’s trust in Bob to grant him some access (maybe view, but not update).  This is based on OAuth and uses OAuth terms. UMA comes from the use case of helping a human (Alice) achieve her goals. It is about helping Alice. With OAuth, you may be flowing your Facebook graph without knowing it. We wanted to make it safe to share health and other sensitive data. The question is, if Bob tries to get access to a resource, can he get in? This is a fundamental access question.


Use case example: I want to control access in a positive way. We want to give Alice more options than clicking yes to share all. This is called consent directives in the health context. There is a notion of a resource server that can be run by different companies.  Alice might have her own choice of OAuth AS.


Eve has been working on specific use cases and ecosystems.  You may want to look at her case studies. One is the online personal loan case study.  It is an Alice to Alice use case, with centralized control.


Abbie asked will UMA integrate FIDO as part of the solution.


Eve responded since UMA is about authorization, it leverages all the authentication underneath.  Gluu has a trust-el protocol.  If Bob shows up and requests access to a resource, there is a system for UMA to enable the server to request claims from Bob (click and he agrees.) Let’s say his context is too weak, so you want him to use higher auth when the authentication is too weak.  In an interaction there are two tokens in place – one for his relationship with the AS and the one to unlock the resource (requestor party token.) You want to ensure the chain is solid the whole way through.  If the authentication is too weak, the whole chain is revoked. If the authentication is weak, Bob could be being impersonated.


Abbie commented this is one nice tie in.


Eve said that is an example of how UMA bakes in knowing enough about authentication to leverage it when needed. I also want to show the story of how UMA enables this loose coupling and where the extension points are. This deck was first created to show the relationship with XACML.  I don’t want to be too identity centric when talking about it. It has different language than trust-frameworks. They have a bias to IDP RP and end users, but don’t think about entities involved in access federations. Is every one familiar with the XACML PDP, PEP language?


Abbie replied I think we are. The conduit is mobile devices. The end point is un-manageable (for customers). There isn’t a single MDM solution that is not hackable.  It wouldn’t stop an inside threat. It gives you fake security. 


Eve there is also the hybrid situation. The doctor has privileges with multiple hospitals.

There is trust that needed to exist before the user shows up. Alice needs to introduce the RS and the AS.  In the most loosely coupled case, Alice has a NASCAR interface to establish trust.

Initially this client is 100% untrusted, and needs to qualify into the RPT (relying party token) so trust-el is a great way to add scope or authorization to a token. The AS is sort of in the PDP role.  Once the protection has been outsourced, it can be a full PDP, and the can be a full PEP.


Abbie asked when do you cover context?


Eve said if ABAC takes attributes from every source, UMA build in the ability to get claims from requesting party and client server’s identity. Those attributes are readily available to the authorization server. There is also the policy inputs that are another type of attribute the AS would need to take into consideration.


Abbie asked what do you mean by attributes? One attribute can pin point the role, than another cover sub-role.


Eve said the kinds of attributes that can drive authorization by default. UMA has a relationship with OIDC and SAML. They specialize in carrying identity claims. On the occasion of a requesting party showing up to get access, she will be asked to provide info to the AS to feed the PDP process. If she has a relationship with an OIDC IDP, then she could get redirected or if she already has a token could proactively push the assertion over.


Abbie asked about the use case.


Eve said it all depends on your ability to tell about multiple URL’s.


Eve said the use case is the employee needs to log into Salesforce.com. The employer needs to find out what attribute/claims to stuff into the token depending on negotiation off stage.  The mechanism in UMA is theoretically extensible.  If you need additional attributes you can go to the IDP, and you can chain IDPs. Ultimately, and really the worst case for UX, you can get new attributes.


Andrew said the AS will need to evaluate a collection of attributes to see if it is confident that a sufficient level of trust is achieved.  If more is needed, the originator may need to provide more.


Eve said the AS plays a central role.


Andrew replied the AS is where the attribute evaluation takes place. If I need more information, the trust-el work might provide a mechanism to request or access various sources, but the process of evaluation would be owned by UMA?


Eve replied I think so.  V0.9 is in public review. This claim profile spec is the heart of where in UMA get attributes about requesting party (claim based authorization.)  It could use SAML or OIDC tokens as conveyor. 


Eve said there is one more relevant concept. There is this RPT; the main token is equivalent to a formal OAuth token with scopes.  In the UMA case, it has permission rather than scopes. Similar to a normal OAuth, it has to look at the list of permissions associated with the token and determine if the current request is covered. There is a piece of responsibility the RS is taking. The AS is stuffing the permissions in. The RS needs to look at the permissions and do the right thing.  So the amount of policy decision making there is a division between AS and RS. You can profile the token for different types of data. The default division is AS does most of the work and the RS needs to evaluate if more is done. This is the JSON bearer profile, like scopes ++. Going to cloud Auth, need to go to entitlements model rather than approve/deny.  You could profile the token to have whatever you want, which takes it further away from a global standard.  In a loosely coupled ecosystem, outsource authorization decision is very scary.  The RPT is the fulcrum. It can support different responsibility relationships


Abbie said that Dazza is the spec editor.  The concept is really important. Federated identity was challenging. Federation authorization needs to be able to be adjudicated if there are problems.  Need to be able to determine who is the source of the problem.


Eve responded thank you.  For more information see http://tinyurl.com/umawg


Abbie said we may call you back again.


Abbie commented Eve gave us lots of things to think about. From a TC perspective, does this help with the requirements? Do we need a requirements section of our document?


Andrew responded that is a good question. I’m still struggling with a conceptual point. Requirements are one way. There is a lot of interesting work around risk mitigation. The happy path is how to assemble more information. There is good work in the MFA context. Here there is a range of questions: what is the information, sources and attributes that are needed.  Additional trust may be requested. 


Abbie said I think the requirement will come from use cases, and need to work irrespective of OAuth and SAML.  We can also build on the previous editor’s sequence. It will take a while to get a consensus.


5. Adjourn


Abbie asked for a motion to adjourn.

Andrew made the motion.

Colin seconded the motion.                                       

The meeting was adjourned.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]