OpenID v. Next
I've posted notes from the session at http://self-issued.info/?p=256.
-- Mike Jones
Convener: David Recordon, Dick Hardt Notes-taker: John Panzer Tags:openid, identity, OAuth, AX, UX, PAPE, Discovery, Attribute Exchange, Security Discussion notes: Agenda:
- OAuth Hybrid
- Attribute Exchange
- User Experience
- PAPE
- Discovery
- XRI?
- Email addresses
- User Experience
- Pop-up
- Language
- Active client (non-browser)
- OAuth (see non-browser client above)
- Security
Discussion about agenda:
Want to figure out what we can do in the next ~6months.
Should LOA above level 1 be on agenda? How important is it to get to level 2? Goal is to understand what it would mean to get to level 2 vs. doing other things. If can get to L2,3 without a lot of complexity or losing important attributes of OpenID, then could be worthwhile.
Q: Does anyone know of any actual known attacks against OpenID in the wild? (Yes, someone claims to have broken any number of RPs)
Yesterday, discussed various security threats that we understand (have been used to attack other protocols) and created a list of threats that are significant against OpenID today. Would be nice if we hit most if not all of them when doing v.next. If hit LOA2 in the process that's great, but most usage of OpenID are consumer web apps and we want to make our current users secure. Solutions are things that we know we can do or are not much more of a step from today.
Proposed sub-teams for next year:
- Security
- API / Data
- Usability
DISCOVERY
Email addresses as a form of identifier. Query: What about other types of identifiers? Can we make anything that resolves to an OpenID be usable? See Webfinger mailing list. Rough consensus that we want to look at email like identifiers, some discussion around usability etc.
Dick tries to take a poll: Do we want to narrow down universe of identifiers or widen? Discussion about usability of having different RPs accepting different types of identifiers. (Need to build persistent, reassignable identifier into discovery.) Ultimately want we want, when a user goes to a site, their OpenID will work no matter what. (=drummond: XRI 3 will be in the form of a URL.) Breno: We don't know yet enough about discovery. Resolved: We don't know enough to make that decision.
=drummond: Set goal of understanding implications if we do or don't address problem. Everyone agrees we need to understand the problem this year (not everyone agrees we need to solve it).
User Experience: Yes we agree we need to improve it. (International requirements may drive UX as well - jurisdiction, etc. is important, Yahoo! has an additional parameter in addition to language to determine jurisdiction.) UX to be merged into v.next (which also means finalizing the UX extension.)
Active Client: Should we support them? 1. Outside a browser; 2. OpenID enabled browsers -- client code that is OpenID aware. Advertising that OpenID is available (XRD discovery)? Is there consensus to give a recommendation to browser vendors on how to integrate with OpenID.
OAuth and OAuth like things: Should we add support for rich clients to authenticate -> API for rich client to call. (Note: Really hard for OAuth desktop app to figure out what happened in the browser.) (Yes.)
JSmarr: Speaking of making rich clients operate with OpenID: 'Direct' auth? (Heresy! Burn the witch!)
Attributes: Proposal from Mike that there's a standard set of attributes and a standard way of communicating them. (Should they be URLs? Or shorter?) Consensus that we need to have attributes that are widely available and with consistent semantics and syntax. (RESOLVED.)
Single Signout: No consensus that we have to do this in next 6 months.
(Call this v.6months?)
Question: Backwards Compatibility? (Or transition period? How much software is in standard libraries that can be revv'd vs. custom deployments?) 2 questions: Can implementations make their own decisions about compatibility modes, are are they forced to be backwards compatible? Can they re-use the same endpoints (do the protocols collide)? Note: If we use the Hammer Stack for discovery, then the "new" discovery will follow a different path in any case.
JSmarr: Discovery of active sessions on OP; is there some way to do this (UX/Discovery)
Mobile Support/Alternative Devices: Want to make sure protocol works well in mobile environment (mobile web browsers?) Esp. dealing with long, long URLs. (2K limit, etc.) Request and return URLs both problematic. Devices that don't have browsers (will there be any of those in 2011?)
Security: Top 3 attacks we want to mitigate? (See above, was separate session on that.)
Votes: "Who is going to work on what" (as opposed to "what should be worked on"):
Votes (official ones to be provided by David & Dick): Discovery: 10 UX: 10 OAuth hybrid/Rich clients: 8 Security: 8 Attributes: 9 Mobile: 8
