Minutes for the meeting of the Electronic Identity Credential Trust Elevation Methods (Trust Elevation) Technical Committee
15 December, 2011
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 |
Brendan Peter, CA Technologies -y |
Carl Mattocks, Bofa |
Cathy Tilton, Daon Charline Duccans, DHS |
Duane DeCouteau |
Colin Wallis, New Zealand Government |
Dale Rickards, Verizon Business |
David Brossard, Axiomatics - y |
Dazza Greenwood |
Debbie Bucci, NIH |
Deborah Steckroth, RouteOne LLC |
Detlef Huehnlein, Federal Office for Information |
Don Thibeau, Open Identity Exchange - y |
Doron Cohen, SafeNet |
Doron Grinstein, BiTKOO |
Ed Coyne, Dept Veterans Affairs - y |
Ivonne Thomas, Hasso Plattner Institute |
Jaap Kuipers, Amsterdam |
Jeff Broburg, CA |
John Bradley |
John "Mike" Davis, Veteran's Affairs |
John Walsh, Sypris Electronics |
Julian Hamersley, Adv Micro Devices |
Kevin Mangold, NIST - y |
Marcus Streets, Thales e-Security |
Marty Schleiff, The Boeing Company |
Mary Ruddy, Identity Commons - y |
Massimiliano Masi, Tiani "Spirit" GmbH - y |
Nick Pope, Thales e-Security |
Peter Alterman, NIST - y |
Rebecca Nielsen, Booz Allen Hamilton |
Rich Furr, SAFE-BioPharma Assn - y |
Ronald Perez, Advanced Micro Devices |
Scott Fitch Lockeed Martin |
Shaheen Abdul Jabbar, JPMorgan Chase Bank, N.A. - y |
Shahrokh Shahidzadeh (Intel Corp)y |
Tony Rutkowski Thomas Hardjono, M.I.T. |
William Barnhill, Booz Allen Hamilton Observer Cathy Tilton Guest Eric Sachs |
|
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.
1. Roll Call
.52 percent of the voting members were present at the meeting. We did have quorum.
2. Agenda review and approval
There were no changes.
3. Approve Minutes
Abbie made a motion to approve all minutes not [previously] approved.
There were no objections.
The motion was seconded.
The minutes were approved.
4. Presentation by Eric Sachs (Google) on Street Identity.
Abbie introduced Eric Sachs from Google, who will be giving a summary of the recent Street Identity working group and their recent conference.
Eric started by saying that a link to his slides was sent out in the chatroom.
Eric explained there was a recent conference held by OIX on the Street Identity Project. This slide deck highlights four topics presented at the conference.
Slide 4 starts with account chooser. With federated login, one of big problems is: what is the user experience for a website that is moving away from passwords. Usability has been poor for options. You can also visit accountchooser.com to learn more.
With account chooser, user can go to new site, click signin and the next screen they see is a list of accounts they commonly use on their computer. Note that it can be a shared computer. They click the one they want to use, the only thing going back to the website is the information going back from the user. It is then up to the website to decide how it is going to verify that information. Then the user will be directed to a standard consent page, then they are logged into the site. There are a couple of Google and Janrain products that make this work. The OpenID Foundation (OIDF) working group is working on a central account chooser. There is one central domain owned by OIDF. Information is kept on local computers. See the Account Chooser working group for more details.
We are ecstatic about what we are seeing from deployments. Any Google user can use this now. We are waiting to roll it out as the default for all uses.
Next Eric talked about Oauth2 and OpenID Connect, another thing he has been working on. The protocol wars for identity on the internet are over. One reason sites have not adopted a solution is they didn’t want to choose the wrong one. Now all the major consumer players have moved to OAuth for a common layer for identity in the cloud. The function of OpenID has been re-implemented to sit on top of OAuth. It supports federated login. Big identity providers have seen increases in adoption. A goal was to make it easier to support use cases, not just federated login to access data at another location via APIs. Now have a simpler, more powerful story.
Rich asked about oAuth2.0. FICAM did not include OAuth. Is anything being done to get it as an approved profile?
Eric commented that for most big players, Fed use cases are not a significant driver.
Don reported that FICAM folks are actively working on a profile of the OpenID Connect protocol that is inclusive of OAuth. So all systems are go for early publication of a profile of OpenID Connect.
Eric stated that OpenID Connect is not yet stabilized. It is getting closer to a formal vote. But those who are close to it have already implemented it. Hope to have vote by OIDF 2/1 meeting. We will have a vote on the implementer’s draft. Anticipate a Q1 formal approval of the OpenID Connect spec.
Shaheen asked Eric if he had any use cases for OAuth and financial institutions.
Eric said they come in two classes. Most uses of OAuth Google sees are not consumer scenarios but two legged OAuth – two enterprise systems making API calls to each other when using RESTful rather than SOAP APIs. That is a large driver for why Microsoft and Google worked on an OAuth wrapper between OAuth1.0 and 2.0. Many participants in OAuth2.0 are from the financial space. It is the standard that Quicken uses.
Eric continued on slide 10. This is where we spent the majority of the conference: how can a website verify the identity of a consumer who logs in. There is a live demo you can find at streetidentity.com.
The example in the demo is the idea of a TV channel that wants to run their own website and wants paid subscribers to log in and prove they are subscribers to receive premium content. We created userid tv. User goes there to login. See the screen shot on Slide 11. Someone has logged in, and site hasn’t been able to confirm if user is a paid subscriber, but notice that I have access to your home address. If user clicks button to use this address, can use this to look-up subscriber. So how did website get access to this address? Previously on a consent page, they agreed to share their verified street address info with the site.
Then the TV website goes to ID/DataWeb and polls the cable providers in that zip code to see if they have a record that the person is a paying subscriber.
Slide 14. See have verified subscription status and user can access content. Go to site, click one button, after two clicks can get access to content. That is the end user experience. How did this happen technically and business wise?
See Slide 15. How was the user’s identity verified? Attribute providers, rather than identity providers, can go out and verify the attributes - could be age, college transcript, etc. Google hooked-up with ID/DataWeb in DC. They have implemented the attribute provide used in these demos.
If the user has consented for the verified street address to be seen, but their address isn’t yet verified, this says there are ways for you to verify your street address. If the user chooses ID/DataWeb it asks the user to self assert. See Slide 18. Then in Slide 19 they send a postcard to your house. When it arrives, the card says come back to the website and enter this one time code.
That technique is a pretty common approach. SSA uses it. Most of businesses that use it find two big problems: a huge falloff in users during the process (it takes multiple days) and it is expensive. Google and PayPal can cost $5-$19. Under this mode, instead of the user having to repeat this process for every site, they only have to do it once ever. Then it is just two clicks. Second advantage is cost. ID/DataWeb charges website for the look-up and it costs them ½ what it would cost the site to do it itself, as Google has optimized the flow. That is just one of many different techniques that can be used to verify address.
Slide 22. After the user with an attribute provider has verified info, they have to link the attribute provider to an identity provider like Google.
Slide23. Technically speaking, one thing we do behind the scenes to make it financially viable is Google hooks sites that need identity to identity providers. Google uses java tokens.
ID/DataWeb only returns no if the RP has an agreement with ID/DataWeb. The bigger goal is to create the financial model, and make it easy to use so there is enough volume for attribute RP and attribute providers.
There was more interest than expected. Some were already using postcards. This is cheaper and has higher yield. The attribute providers, many see potential, but they needed to feel that there was enough $$ to justify the investment.
Google is live supporting this.
Abbie asked how do you rate the quality of the claim of an attribute provider?
Eric said we started to go after a market that already existed. So we said it is equivalent to a decision already made. Next question is not about doing a post card, but about needing in-person proofing. For example customer would like to pay X for in-person proofed credentials per year. The market size for that is much smaller, but they are willing to pay more.
Next, imagine there are lots of attribute providers. How does a website decide which to trust? We don’t see that now as a protocol problem. We see that as an OIX role to certify providers at different levels. We are not getting a lot of requests for that right now. ID/DataWeb has used lots of ways to verify identity, each of varying quality.
Abbie gave a phone example. He pays for 4 phones (used by family members.) The phone billing address and verification is for him, not his family members. So phone validation doesn’t work for everyone.
Eric commented so there is this per user problem. Verizon has a whole department for doctors doing proscribing, that is one end of the scale. There is a wide range of situations. If there is a single phone in the phone contract, one can be more confident. They may not be able to use the account with the example you gave.
Abbie asked do you take into consideration the health of the device? (virus, security, etc.)
Eric said the 4th section of the presentation is on strong auth, which is about device specific issues. See Slide 25. How could the website get confidence that not only the account but also the session was secure? The presentation focused on session auth. It didn’t focus on malware. Eric started by explaining that we have many technologies for strong auth. Google has a server opt-in that requires a second form of auth any time you use a new computer. It sends a one-time code to your phone. Others have this also. Are we going to see broader adoption of strong auth? Users hate the usability. What is the business model if one company does strong identity?
Eric talked about how a website can make a call to an attribute provider and will pay to get attributes. The provider can say for this session, they have authenticated the user and the website has to pay. There are slides for this session online. Was on a per session basis, not per account basis. In some cases there was chaining of devices. Go to street identity.com and you can also view this video.
We still see the bigger challenge is adoption and usability.
The best people to promote this to are sites that have been hijacked. So did this. They found that very few people did use the multi-factor option. Of the people who did, the majority would turn it off after a number of weeks. All the big consumer sites are having problems with account hijacking. So maybe will get help with adoption.
Google gets asked why can’t the mobile phone co’s get into this market. Phone companies’ traditional response is that yes we know how to do this and for $10 per year we will. The idea of pooling users at 10 sites for $1 each is starting to be discussed. Eric talked about how this could be used. Google sends back a half cookie and then the user needs to add password. The combo gives access to an account. This user experience is streamlined compared to previous approaches.
If the user gets a new PC, they might need to use their mobile phone to scan a bar code on the PC or something. Google wants to keep a cookie trail of how that device was authenticated and the history of the device used to bootstrap it (e.g. Bluetooth and smartcard on device.) That is a lot of info. May need to consolidate it.
Slide 31. Eric said interest was high enough that there already was a follow-on meeting on Monday.
Don summarized that they talked about 2012. The plan is to move from talking to experiments in real world. There are two things going on concurrently. The first is the OIX attribute exchange working group, which is drafting a trust framework and setting up a standard for what a trust framework would look like. The second is a series of pilots in two phases providing real world feedback. The second phase of pilots is later in 2012 to accommodate folks who want a more back-end policy framework and US government agencies using the postcard method.
These pilots are focused on a simple use case that is a basis for learnings that could inform this TC: how can we use learnings from the exchange of simple and important attributes and integrate them to trust elevation strategies.
Peter said this is a very interesting, and new way of considering things and the interaction between attributes.
Abbie said we need to visit the FISC steering committee– working with WH – need to work with Eric on what doing.
Abbie will set up meeting with Eric and this group
**Action item taken for Abbie to set up a meeting with Eric and this group
Abbie asked if there were any volunteers to liaison.
Rich replied he was extremely interested and volunteered.
** Action item taken for Rich Furr to be a liaison.
Abbie asked if there were objections. Hearing none,
Abbie move to appoint Rich Furr as our liaison officer.
Rich thanked the TC very much.
Abbie said he really appreciated this and look forward to a closer relationship
Abbie announced that the latest version of 800-63 (800-63-1) was approved and released. See December 13th PR. http://www.nist.gov/itl/csd/sp80063-121311.cfm
Abbie explained that for the next TC call on January 12th we will have a special presentation on x1254. For the following call there will be a presentation on FSI standards on auth and strong auth.
Abbie said we are getting international input and should be in very good shape at a document level by our face-to-face in March.
5. Mary and Editors to provide an overview of Committee Draft of first deliverable
There wasn’t enough time for this topic. It was suggested that we get John Bradley or Tony CGGP to speak about how to transmit for level 3, and also SAML binding at some point.
**Action item to get John Bradley or Tony to speak about how to transmit for level 3, and also SAML binding at some point
7. Conclude meeting
We ran out of time and Abbie made a motion to adjourn the meeting, and the meeting was adjourned
Log of chatroom script follows below:
>>>>>>>>>>>>>>>>>>
Please change your name from 'anonymous' using the Settings button
anonymous morphed into Mary Ruddy
abbie: CHAT ROOM
http://webconf.soaphub.org/conf/room/trust-el
Passcode: 637 218 8139
Int'l Toll: 1-980-939-6928
abbie: toll free 1866 222 6652
abbie: Agenda
abbie: 1. Roll Call
2. Agenda review and Approval
3. Approve Minutes
4. Presentatio by Eric Sachs (Google) on Street Identity.
Eric Sachs from Google will be joining the TC call to give a summary of the recent Street Identity working group and their recent conference. During the call you might want to checkout the online slides and follow along yourself. Alternatively, you can join the Google Hangout that Eric will be running to show the slides. You should be able to join it by clicking this link when the meeting starts. Or you can follow the G+ Identity Helper profile that Eric uses for his identity work at Google. When he starts the hangout, his profile will display a link so that you can join it.
5. Mary and Editors to provide an overview of Committee Draft of first deleiverable
6. Attendance Update
7. Conclude meeting
anonymous morphed into Eric Sachs
abbie: Street Identity working group https://sites.google.com/site/streetidentitylmnop/workinggroup
abbie: checkout the online slides https://docs.google.com/present/view?id=0AWRF6Ca-4HNnYWpraHA1aHBwM3R0XzEzMGZ3dDdmMmRq&authkey=CMmct4sP&hl=en_US
abbie: to join the Google Hangout https://talkgadget.google.com/hangouts/extras/talk.google.com/identityhelpermeeting
abbie: you can follow the G+ Identity Helper https://plus.google.com/116241727483324246886/posts
Don Thibeau Open Identity Exchange : Please forward the link to the Bank of America Presentation (Sorry I missed what was a value adding look at tokens today)
Eric Sachs: Eric Sachs just joined the call
David Brossard - Axiomatics: Hi everyone
Mary Ruddy: Massimiliano can you join the call?
Shaheen Abdul Jabbar: if there is a presentation that is hosted at google which will be used for presentation today, please forward it as I dont have access to google sites
Eric Sachs: Could someone with Shaheen's email go to the slide deck, and choose the Actions button at the bottom and save it. You can then email it.
abbie: hi docuemnthttp://www.oasis-open.org/apps/org/workgroup/trust-el/documents.php
abbie: street identity slides
Shaheen Abdul Jabbar: thank you. got it
Massimiliano Masi (Tiani Spirit): Hello,
Massimiliano Masi (Tiani Spirit): I just joined the telco
David Brossard - Axiomatics: I lost you guys
abbie: welcome back
Don Thibeau Open Identity Exchange : Abbie the point you made earlier is well made-- re the TC needs to be thinking across protocols SAML, OAuth, OpenID Connect, engaging industry leaders with first with Bank of America, now Google, next Verizon, then looking for innovators to share new views to better understand / tie online and token based solutions to trust elevation methods
Peter Alterman: +1
David Brossard - Axiomatics: In Sweden, when creating an online account for utilities, e.g. electricity, you can use your Google OpenID. To link it to your actual electric account, you need to enter your customer ID and a unique code printed on the latest bill. This proves you own a paper bill (which indirectly proves you have access to the mailbox at the address the utility company has)
David Brossard - Axiomatics: (ok that's actually an instance of the postcard)
Don Thibeau Open Identity Exchange : One way to think about it: OpenID Connect standardizes a protocol for the exchange of attributes (on top of OAuth2.0) ...it enables.... The OIX Attribute Exchange Working Group now drafting a trust framework for Attribute Exchange for various parties to implement various instances of a trust framework for attribute exchange....it enables...a trust elevation strategy that selects from a menu of multi factor authentication options
Don Thibeau Open Identity Exchange : Google, Verizon and others will be testing this proposition in real time, with real customers, with live data at scale beginning in 2012 via the OIX Attribute Exchange Pilots in two phases. The hope is that others including some US Government agencies might participate in the second phase of the OIX AX pilots to tak advantage of the output of the OIX AX trust framework Working Group's deliberations on the legal, business and policy aspects of attribute exchange
David Brossard - Axiomatics: what happens when a user loses their cellphone? Those phones are so advanced now that they contain too much information about a user... Not only does it contain access to the user's email but it also has the user's OTP apps...
Eric Sachs: David, for your question see https://sites.google.com/site/streetidentitylmnop/workinggroup/lmnopap
Eric Sachs: That is linked from the streetidentity working group, and covers a ton of attack vectors and edge cases like the one you mentioned
Peter Alterman: Isn't your smart phone password protected? Secondly, as soon as I lose my cell phone (or it's stolen) I call the provider and have it shut off.
Eric Sachs: Yes, but Google controls the user's password while Verizon controls the phone. So we get some improved security by separating the 2 factors. For example, even if Verizon turns evil, they can't break into the user's account.
Don Thibeau Open Identity Exchange : lose your cellphone --your back in the 1990
Eric Sachs: The link I posted for David covers some of those threats Peter
Don Thibeau Open Identity Exchange : FISC's efforts are aligned with this efforts in theory and should move to real world collaboration soonest
Don Thibeau Open Identity Exchange : thanks Rich we can talk more offline about the liasion activities
Don Thibeau Open Identity Exchange : send use cases to mary