Yahoo! As a relying party

Session Topic: Yahoo and Relying Party experience (T2C)

Convener: Mike Lee, Andy Wu, Yahoo

Notes-taker(s):Jim Epes

Tags for the session - technology discussed/ideas considered:

Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:

JIM EPES NOTES:

Last fall piloted on FlickR using OpenID only. To eval UX, engagement, new user acquisition.

Launched global support in q1 11 for OpenId, Google acct, Facebook Connect evaluating engagement performance and impacts from IDP permissions 00 performance, conversion…initial performance is positive; applying changes based on findings. Want to understand user age since some services are age specific. …

Seeing considerable flow of new users. If I’m providing a service to someone who wants to comment on a blog post, rather than recruit entire new email account, that makes sense.

E2E Flow: Facebook with Hotmail ID…login with non Yahoo address…you want to comment on Yahoo chat but don’t have account; today you take them to traditional Yahoo login page, or to sign in with FB or Google. FB renders the credentials pop up and presents what info to present. Some FB info is core to authn, other is asked for. When Yahoo asks for access to FB info it is binary – you either allow it all or deny it all. That’s how FB works. The TOS for this is preset within FB but the Yahoo TOS is presented in the next step. This is a one-time event and is replicated the next time you log in. Just before you finish you pre-declare the FB info (name, email, etc.) that is being collected so the user can review. There is opt out for sharing updates from Yahoo to FB. A lot of people choose that.

The one-time admission of info transfer from FB to Yahoo is NOT subsequently editable in Yahoo at next time of OpenID login on Yahoo; you’d have to go into FB and edit permissions on that end.

Conversion performance: From Yahoo to logon page: 34% FB and 55% Google. Full logon completion is 73% each of prior logon visitors, for total completion rate of 25% FB and 41% Google.

IF the user has a Yahoo account, they suggest the user link the OpenID account and the Yahoo account. This creates a second account.

The result is that fewer people complete from logon page: just 46% FB and 30% Google, for lower overall completion to 16 and 17%. Thinks it may be confusing.

3rd party auth is what they use: a combo of Open ID and Connect.

Metrics: Andy Wu

56% of Goog signed in UU’s access Flickr (then Sports, Frontpage, Answers, Groups) 39% of FB signed in UU’s access Flickr, followed by mail, front page, Sports, Answers, Groups

3PA Metrics: “Considerable” % of WW good registrations driven by 3PA. US Properties drive highest % of registrations. (“Good” = total reg-obvious abuse)

A Majority of all new user registrations for Flickr is driven by 3PA, and sizable referrals rates for Groups, Sports, Answers, Games.

Largest referrals to 3PA new user registrations referral comes from Flickr

Not seeing significant cost impact in terms of compromised accounts, customer support calls.

3PA engagement depends heavily on which Yahoo property you’re looking at.

The non-mail services have 65% conversion for FB and 77% Google for getting to Yahoo login return from FB/Goog 41% FB and 43% Goog on Front Page/My Yahoo 22% FB and 17% Goog on Yahoo mail. Not surprising since these folks actually HAVE a Yahoo account so they might have just been checking this service out.l.

Completed conversion is 83/84% for non mail services So…Property is most critical driver for conversion and usage. Mail is NOT a driver.

Lessons: engagement call to action needs to be more prominent in the referring service

3rd party account creation engagement is on par with traditional Yahoo ID reg

Existing Yahoo users are not feeling compelled to use 3PA; confirms goal to reach new users. � KAREN P. LEWISON NOTES: A high-level architecture designed to meet the privacy goals of NSTIC in the short term was outlined, including 3 use cases (see Power Point at http://pomcor.com/ documents/NSTICProtocolSteps.ppt and a revised White Paper at http://pomcor.com/whitepapers/NSTICWhitePaper.pdf )

Points raised during the discussion period included:

--Identical privacy goals to NIST's were described by the OECD over 30 years ago, but not enforced.

--Also, in Europe, the concept of trust networks to ensure a chain of responsibility for user's data has been important in developing regulations.

--Some audience members from Europe were interested in the exact official formulation of NSTIC's privacy goals; they were directed to the official website at http:// www.nist.gov/nstic/news.html

--Other issues with the proposed architecture were the resultant increased costs (which would lead to cost redistribution to users), and decreased access speed.

--The proposed protocol is best seen as an enabling technology tool, to demonstrate to

policymakers a short-term implementation of most of the privacy goals of NSTIC.

--Question whether this is a possible building block to fit into OAuth 2.0, versus an OAuth killer? Answer is: likely neither.

--Audience members raised the issues of whether the UMA protocol, or a browser- based authentication app from the group at Newcastle University have already solved these problems.

--Another acknowledged objection was that this architecture requires extensions of the HTTP protocol to enhance the role of the browser in increasing privacy of double- redirection log-in protocols (possibly to be discussed later this month at the W3C Workshop on Identity in the Browser).

--As pointed out by Kim Cameron at the end of the discussion, if the RP and IdP collude, they could find out the identity of the user. On subsequent consideration, this is not an issue in social log-in, but is a shortfall in other use cases. Hence, this is more of an interim short-term solution, outside of social log-in, and the definitive solution likely lies in using anonymous credentials based on zero-knowledge proofs.