These are my notes from the technical summit. They may be incomplete, or somewhat inaccurate, but I provide them as background from the event. — Chris Messina

Day 1

OpenID v Next

problems

solutions

action plan

Presentations

Google

OpenID Improvements

usability

messages

big providers with big databases: wait

when will we tell them not to wait?

when Google is an RP... no great examples today to use as example

large IDPs offering multi-factor auth

proven best practices for installed-apps using OAuth

good software/services exist to provide full lifecycle mgmt for upgrading existing registered users/federated users

bonus: solve problem where user has services that come from providers that don't also provide their identity

i.e. tokens for 3rd party apps

4LO anyone?

willing to take a risk but want more users: try to figure it, use RPX

if you don't like NASCAR, pick a single provider and outsource to them

what I'd like to see

focus on large OpenID IDPs becoming RPs

installed apps, WRAP, email verification, mobile UI, account recovery, 2FA

less focus on IDP functionality or even protocol standardization

low-hanging fruit

email verification

Digg

Bill Schupp

Motivation

difficulty to prioritize

negative perceptions

shitty UX

security problems

no single sign out

dislike of auto-login

easier to become easier to sell now

easier to sell b/c more awareness with internet identity

Implementation

unable to use existing libraries

...we need better libraries! (on server side and client side!)

clearer spec for v.Next (hard to use for first-time implementors)

XRI is being skipped in a lot of libraries

need better test tools (continuous integration)

UI/UX

which providers to highlight/feature?

of 14K respondents: Google, Facebook, Yahoo, Twitter, MySpace, LinkedIn, AOL, myOpenID

45% familiar with OpenID; 22% had used

can we have a streamlined registration process?

tried amazon-style approach... made flow more complex

many different experiences

Facebook, Twitter, OpenID, etc

Need for UI libraries

Facebook

Luke Shepard

what they've done

relying party with OAuth Hybrid

registration & contact importer

linking identities

not a provider

"supportive of OpenID" "giving developers choice"

results

benefits

marginal increase — 7% improvement for inviting contacts (if you're already signed in)

decrease by 20% when user is not logged in — compared with screenscraping

costs

engineering cost to implement

ongoing bugs interfere with results

Google/Yahoo have worked closely to improve flow...

hard to mix SSL

realm matching too narrow

POST on response makes it a headache

open source library - 15K lines of code - too complex

why not become a provider?

developers not asking for it

#1 request: make it simpler, easier to use, more robust

OpenID could make it easier but doesn't today

"implementing server side code would result in losing 90% of their developers"

should be able to implement with copy-paste

Think beyond the web

mobile

desktop

consoles

web

OAuth is simpler: build upon existing relationship

library support comes when the protocol is simpler

x-domain receiver file has tremendous dropoff (30%)

make the AUTHN/AUTHZ much easier; rest will follow

Windows Live

Sarah Faulkner

What Windows Live needs from OpenID vNext

easy to implement, well understood protocol for developers of various application types on various devices

well understood, optimized end-user experience

#1. email address as identifier

creation

confusing value prop

user drop-off

naming frustration

use

which ID to use?

name retention

delivery - overhead

overhead in supporting a new kind of identifier

forgot password flows

#2. rich client and devices support

rich client: windows, mac, silverlight

devices: mobile, TV console, picture frames, etc

#3: Authn + Authz

so much more than "just authentication"

OpenID + OAuth — need access to user data

#4. network sign out

WL is making continued investments for SS-out across WL network

single sign-in — major benefit

network sign out: security issue

"sign out is sign out"

Netflix

#1 Customer satisfaction

#2 devices devices devices

devices can't do OpenID

moving beyond the web

#3 Liabilities and Laws

When OPs fail — who is liable?

whitelisting/blacklisting

if user is paying for premium service but can't sign in b/c OP is down... you must stop billing user... user also can't cancel... 

Yahoo Small Business

Sabari

Too early for Main St ecommerce?

Yahoo Merchant Solutions - 12 yrs old

45K merchants

more than top 500 stores

merchants recognize benefits of OpenID

trust

speed

convenience

...but no benefit to making the sale

concerns

lack of mainstream adoption — no enough RPs

concerned about adding steps to checkout

another problem: success of Facebook Connect (divergent/similar solutions)

not seeing a lot of stats promoting benefits of OpenID

why do I need to support all these providers? cost of ongoing support due to nascent standards

main goal is converting customers/shoppers

usability standards —every popup is different

buyer privacy concerns (ability to control what info is shared with merchant site)

merchants concerned that savvy users want more controls over what information they share with merchants...

what is needed

more ecommerce-specific profile data

billing address

shipping address/verified data

stored payment information

portable reputation

"age of account"

"badges" or "reviews"

standard OP behavior... look and feel, data being exchanges, performance

one ring to rule them all... open source RPX-like solution

security (certified OPs) - "trustworthy"

How does this interact with PCI compliance once you hand out credit card numbers in the browser?

merchant interest coming from media awareness... think of facebook and twitter as viral channel — less OpenID

LinkedIn

Mike Repass

LinkedIn Platform

OAuth fundamental

Currently not an OP; evaluating identity space now

developers rolling their own LinkedIn ID via OAuth

developers don't want to read specs, want turn-key solutions; want to trust standards bodies

LinkedIn Biz + OpenID

biz model complexity

sensitive info (professional)

nontrivial visibility rules

rich profile data (complex schema) — people think about "LinkedIn Profile" — rather than "LinkedIn ID" or "account"

so:

linkedin <> developer trust is critical

most scenarios require developer registration

knowing who developers are

monitor, control, restrict

developers must have privacy policy

is there value with reg-free OpenID?

OpenID value props

easy adoption for basic scenarios

reg-free, works with any site/partner

limited due to trust aspect — OAuth upsell...

OpenID + OAuth hybrid

fits with existing program

but concern about dev complexity

free libraries

code available for most platforms

PAPE, common auth solutions, etc

Problems, Wishlist

limited ROI for reg-free

dev complexity/headaches

need stronger concept of trusted-only OPs

need stronger developer message re: Hybrid

killer feature drop-in "trusted profile" lib

developer understands it's per-provider

standard get-a-key treatment

a uniform profile object w/ extensibility

"hydrate a profile object"

need tighter controls around profile fields (AX)

Options

basic OpenID + OAuth

openid + minimal profile data

most scenarios: recommend OAuth APIs

rich/LinkedIn-specific OpenID

require registration + key (basically hybrid)

developer complexity?

no openid, just oauth

optimize flow

standard profile endpoint?

Q&A

lots of JS devs that come and ask about

desktop apps in enterprise is huge

don't allow profile storage on 3rd party apps

❑

Paypal

Ashish Jain

Developer API

is this a valid paypal user?

SSO + attributes

paypal has >1000 attributes per user

SSO + rich attributes set

data sharing w/o user present

Wants

common SDK/library

common user consent flow

common key mgmt requirements

developers are overwhelmed by key mgmt

common partner onboarding process

developer API - multiple APIs, multiple SDKs, learning curve.

RP onboarding

open source libraries

Paypal wants to move away from maintaining proprietary code

interoperability issues

automated testing tools

RP certification (e.g. ICAM profile compliance)

critical for Paypal for sharing address, sensitive data

Security

Security is both a feeling and a reality.

Reality. Perception. Action.

Session swapping issue

need to be addressed from a spec perspective

independent security evaluation

identity/acknowledge all the issues

Gamestop

Charlie

Gamestop/Game Informer/Power It Up/Jolt Online Gaming

all have their own user siloes

mostly interested in internal federation

looking to collapse identities

8+ username/password combos

reduce abandons for joining new channels

provide a centralized view of site users to improve analytics

add value to GameStop IDs in the gaming community... IGN is looking at it as well as GamerDNA... but no real adoption

Gamestop checkout...

currently use credit card for online transactions...

users have to authenticate twice to checkout... big problem for conversion

don't want a perceived "channel swap"

no solid solution for non-web techs (i.e. mobile apps)

OpenID isn't ready drop-in technology...

Amazon

Bharath Kumar

Issues Adopting OpenID

Implementation issues

OpenID + OAuth: need richer data...

needs tighter integration... feels like two separate protocols.

multiple secrets — extra roundtrips

OpenID Connect?

URL length

every extension adds overhead

UX Issues, Single Logout

Protocol issues

dynamic trusted associations

whitelist/blacklist?

onboarding process

trust model/certification

Security

perception...

ICAM profile is very good...

OpenID profile for "high value transactions" - HVT

Q&A

what business problems does openid solve?

acquisitions/subsidiary partners...

onboarding merchants (similar to yahoo)

Yahoo

Allen Tom

How do we get Yahoo to be an RP?

350M+ active users

know how to use u/p

we don't want to confuse them

NASCAR — already a huge overlap with other providers

account linking/dup accounts

offer it, but really bad UX

alternatively don't offer it

fragmented user experience

account merging nearly impossible to automate

i.e. merging picasa + flickr account... probably not desired...

a/s/l

age, sex, location

yahoo reg requires this information

although asking fro a/s/l add friction, made biz decision to require it

inconsistent implementation of AX

AOL provides data; Google doesn't

affects monetization

email address

yahoo OP only returns user's Yahoo (verified) email address

other OPs don't

can't be used to automatically link existing accounts

users can have multiple yahoo accounts with the same alternate email address

users need to tell us which YahooID to link with, and enter the password

Customer support

users don't know what their OpenID is

openid 2.0 provides machine-generated identifiers

yahoo doesn't know the user's OP userid

user can't call our customer care and tell us which account they're using

probably will require the user to register a unique local userid so that they can identify themselves out of band

Client apps

need a password for mobile, devices, rich clients

yahoo IM

OpenID Value Proposition

single account to rule them all...

reality just password convenience?

GSA - Government Requirements; US and Beyond

John Bradley/Protivity

problem

Gov't needs multiple LOA

openID currently supports LOA1

users get LoA 2-3 credentials from multiple providers

bad UX, different IdP for different sites

levels of assurance

OMB 04-04

NIST SP-800-63

most gov't websites can't accept PII

Meebo

Chris Szeto - Sr Director of Product

Problems that Meebo faces distributing multiple 3rd party identities and services

The Meebo Bar

it's on 4000 sites, 85M monthly uniques

3 problems

relevance: which services should be shown to the user?

which services are the user currently signed in to right now?

performance: too many JS-based services; slows down page load

all these requests bother publishers... decreased performance

x-has-session parameter useful — but need to ping several providers

inconsistent auth: is OAuth working if not all of your services are using it? (confusion means lower engagement)

❑

❑

Japan

Nat Sakimura

Haraguchi's 5 Principles on Identity (and OpenID)

minister of public mgmt, home affairs, posts & telecommunications

no 3 of jap govt

announced 5 principles on identity

5 Principles

protect citizen's right

not government numbering citizens...

used to receive service from gov't

must be provisioned accurately; no duplication.

self-informational control

identity attr exchanged based on "contract"

inspect and correct self-information

specify the purpose of use, privacy must be protected

pseudonymous identifiers — state purpose of information

information must be protected by most current encryption

identifiers must be un-correlatable beyond appropriate sectors.

cost minimizing and efficient

leverage existing infrastructure

avoid duplication; use private sector infrastructure

leverage gov't infrastructure; standardize data formats

central and local govt must cooperate on implementation

...and work with private sector

interoperability is key

usage logs need to be monitored by user at each RP and OP

to assist RPs should send logs to OPs

❑

some other re

mobile support (70% of customer base)

LoP: trust RP?

contact service

RPs need to get in touch with user

emails are correlatable

Standardized attribute URLs

verified billing/shipping... stored payment info

-> higher LoA

UMG

Lee Hammond — Interscope

using RPX since Nov 08, running on 200 sites

"we're not sure what to do with the user that authenticates using Yahoo"

not a viral channel/public profile

wildfireapp.com

citizennet

peoplebrowsr

js-kit

meebo

9 CMS databases... working with RPX... but separate customer records across all of them

Janrain

Day 2

Webfinger

John Panzer

New account URI -- interesting identifiers

bob@example.org

somecompany.com

mydomain.com

cliqset.com/users/jsalmon

Interesting personal metadata

...profile data

...activity streams

...photo sharing

...email provider

...payment service

Webfinger

acct: URI scheme

use GET at well-known endpoint

yields XRD document with rel="lrdd"

contains links to user services/metadata

Salmon

mention

verify a salmon from an acct:

ask an IdP to sign a salmon on behalf of current user

Browser-Assisted Login

Mozilla

Dan Mills

goals

single user-entry into account mgmt

consistent messaging across all login methods

consistent visual design 

don't break content, gracefully degrade

challenges

different user input req's

complicated error paths

inconsistent deployment characteristics

different websites are different; web is varied — so many ways to do the same thing

approach

standard site-provider metadata describing capabilities/endpoints

built-in browser chrome that reacts to that document

a way to determine signed in status

extensible site metadata to support refinement and innovation

take-aways

definition of at least the common cases of user auth is important for automation

taking a holistic view, inclusive of other relationships is key

Replacing the NASCAR with experience with the identities you actually have

Mike Jones, Microsoft

NASCAR experience has sites guess what identities you have

works for large OPs in NASCAR page

poor experience when using vast majority of Ops

hosted sites, like asu.edu

Solution

enable you to bring ID to sites

requires active clients

benefits

practical user choice

aligns with openid vision

consistent experience

phishing protection

req's

RP must publish requirements to clients

RP must detect presence of client

RP to invoke client

What about rich client apps?

API could invoke active client

triggers interaction with OP

delivers security token to application

protocol details TBD

possible relationship to WRAP

Closing thought: personal OPs

a personal OP in your active client

no conceptual reason on a 3rd party OP needed

ultimately example of bringing you identities with your site

Mixing protocols for fun and profit

somewhere on the internet

enterprises

varying in sophistication

likely looking at cloud interaction

retail relying parties

multiple web properties

existing solutions

enterprises need breadth

discovery not needed

authentication taken care of

rich clients easier in some cases

retail RPs want depth

discovery: YES plz

auth: YES plz

no overhead, no confusion

how to mix?

introduction service

protocol interaction as voluntary form fill

no reliance

reduces typing but doesn't impact authn

facebook does this today with gmail for reg/contact import

gateway service

openid is used as first level authn mechanism

step-up authn is used for higher value xactions

Gateway Mitigating Issues

Free-For-All

any resource can be enabled to directly consume OpenID

OpenID transformation/proxy more likely

issues

UI consistency

functionality mismatch

non-starter for anything for proprietary

Brian Ellin

RPs want

easy sign in, reg

engagement

simple developer tech

solution not tech

RPX?

widgets & API to add 3rd party authn, more

implement in an hour, w/o prior knowledge

OpenID: Google, Yahoo!, AOL, MySpace, Verisign

Also: Twitter, Facebook, Windows Live, LinkedIn

Challenge: provider interop & policy

not all providers support same things

implementations change (mostly additive)

there are MANY provider quirks

developers end up managing lots of provider-specific code

Most RPs don't have resource to track/implement features, policy, etc

Non protocol workflow is hard

simplifying workflow instead of complicating

linking/merging accounts

account recovery

bolting on to existing account

Discovery

most complicated part of OpenID libs

important for decentralization, but slow

already have custom cost for each IDP and most traffic comes from top 5

OpenID and SSO

many people expect SSO-like functionality from OpenID

sign in once, sign in to all widgets

Hybrid: context of consent

asking for full access to social, contacts at authn time could lead to user being surprised later

also, coding openid+oauth is a pain

other issues

realm-specific identifiers

giant AX payloads introduce need for the POST-redirect which is slow

they just made everything required...

everyone wants updated profile information (updated email, etc)

talking with RPs

few care about tech

want their hand-held — told how to integrate, step by step guides, code samples, best practices

want to work with specific providers (X, Y, Z)

Contract Exchange

Nat Sakimura

Artifact Binding

solves problem of long URLs

easier to implement

Making OpenID + OAuth Simpler than the Sum of its Parts

Hybrid is good, but hard

Could identity be part of OAuth?

developer simplicity (bearer token model)

vendor-specific hybrid protocols have identity RPC...

federated challenges

EasyHybrid

use .well-known/auth

RPs can make identity RPC after swapping OAuth verification code

response contains stable identifier

returned token has RP-audience baked in

RPs can use (OP-domain, identifier) as DB key for storing data locally

RPs can use (OP-domain, access_token) as session cookie

What are we giving up?

not backwards compatible with openid 2.0

open questions

Multi-tenancy at Salesforce

overcoming internal perceptions

phishing

broad spectrum of customers and market segments: prosumer -> large multi-nationals

architectural challenges with common login services

prevents domain-specific un-authenticated behavior

forces highest common denominator

merrill lynch, big cos are forcing them to approach sign in to act a certain way

can't ask user base to provide URLs

high common denominator prevents NASCAR

move to namespaces URLs, but damage is done

cisco.salesforce.com is used for login

no pre-authenticated behaviors

most concerns proxy for trust

mid-market and enterprise customers want explicit trust

customer make individual trust decisions

renders discovery largely irrelevant aspect of protocol

even w/ explicit trust, assurance levels aren't there

PAPE support varied and weak

NIST Assurance levels are a start

need stronger assertions of how OPs comply

need to mitigate risk of email provider as OP

Including public policy in vNext

Mary Rundle

background

public policy as obstacle

designing for public policy req's can help with deployment

examples

need higher levels of assurance, protection

LOA: need to know that they can rely on authentication information

LOP: identity disclosers need to know that identity info will be treated properly

samples

reliability: receivers of info want tech to help show that policy req's for higher LOA have been met. Relates to data quality.

should vNext support certification whitelists?

informed user consent: law calls for IUC... 

will UI vNext help users understand

auditability: identity disclosers may want to know that data is being treated properly, with the ability to perform audits

will vNext enable audits? Should it?

basic analysis

reliability/data protection driven by public policy

jurisdictions have data protection req's that come in to play

collection limitation

data quality

purpose specification

use limitation

security safeguards

openness

individual participation

accountability

deployment

if you don't meet public policy req's, you might not be able to deploy OpenID

Implications

for sake of deployment, don't you care?

proposal

vNext needs a process to hear from policymakers to factor public policy concerns into design... so: have a process.

Email Address as User Identifier

Sarah Faulkner

Discovery

who owns it? Gmail on WLID account...

How to find it? Webfinger, NS owner...

Privacy concerns — email address as PII

UX — how do we explain this to users?

problems

what's the identifier? is this a person that we've seen before?

discovery

treat sign in box like search

"search for me on the web"

email-style verification/part of profile?

optimize return experience

What Yahoo wants from OPs

Allen Tom

Contextual branding on approval screen

Existing Yahoo Registration Fields

first, last

nickname

age (COPPA)

birthdate (personalization, ad/content targeting)

gender (ad/content targeting)

location (ad/content targeting) - zipcode

Same identifier for all realms

no PPIDs (pairwise pseudonymous identifiers)

great for privacy; terrible for developers

Yahoo may run multiple realms, we want to correlate the user across all Yahoo properties and partner sites

email address

developer/QA

email address

no proxied emails

ID correlation

identify existing accounts

help users find and connect

email normalization

identifier that the user knows

users need to be able to identify their account out of band from openid protocol

customer support

email address would work if yahoo req'd verified email address for a YahooID (we don't)

abuse/reputation

CAPTCHA

account creation date

reputation

OpenID Summit Certification/Whitelisting

Eric Sachs

IDP Certification Profiles/Use Cases

synchronous email validation (no-inbox verification)

RP Whitelist/Certification

What would Google require from email-based IDPs to "not confuse half a billion users"?

uptime, usability, email verification, attributes, future logins, contract

OpenID Logout

George Fletcher

local site logout

simple, clear, easy to implement

user might be confused because they're still logged into OP

eg

user is logged into gmail in one tab

global logout

difficult to implement

logout becomes a "ui event"

probably requires some level of redirection

OP must maintain and notify all sites where the user logged in

issues

sometimes you want it, sometimes you don't

users don't want to be asked

it's situational

in the middle of a session, do local logout

at the end of a session, global logout

solution?

best option may be to leverage an identity agent on user's device

Non-browser apps and OpenID

Mike Jones

examples to borrow from

WRAP rich client profile

Yahoo, Google, Facebook, Flickr, Twitter, Netflix, iPhone apps, Android, Live, etc, rich client apps

WS-Trust

assumption of desired end state

API or library to retrieve security token

used by rich client apps

implementation performs identity ceremony

discussion/topics

do we assume there's a browser surface?

netflix can use different browser

authn is required for payment in embedded apps

i.e. pay for play... micropayments... games...

enabling multi-factor authn

integrating certs/smart cards as authn method

what kinds of tokens to support?

openid, SWT, SAML, U-Prove

enabling optional smart client

are there any issues specific to mobile phones or entertainment devices?

crypto chip in phones, devices an asset

registering custom URL handlers

what control does OP have over ceremony UX?