Minutes From Meeting Today

[Recordon, David]

Thanks to everyone that attended!  Next time I'll do a better job at
announcing this earlier.  The current plan is to have a draft of the
OpenID Authentication 2.0 spec this coming Tuesday.

OpenID 2.0 Technology Summit
June 23, 2006

Attendees
- Johannes Ernst - NetMesh
- Hemma Prafullchandra - VeriSign
- Pete Rowley - Redhat
- Josh Hoyt - JanRain
- Larry Drebes - JanRain
- David Recordon - VeriSign
- Dick Hardt - Sxip Identity
- John Merrells - Sxip Identity
- Drummond Reed - Cordance (phone)
- Scott Kveton - JanRain (phone)

Trying to Accomplish
- Changes between 1.1 and 2.0
- How can OpenID and DIX fit together from a technical perspective?
- Platform that doesn't block collective ambition
- Room to grow as the stack grows
- Move aggressively
- Feedback about changes being proposed
- Sxip 2.0 borrowed ideas from OpenID and other URL based identity
systems.  OpenID 2.0 is another iteration of borrowing from Sxip 2.0.
Working toward convergence.
- How can these protocols converge?
- Something that actually works out there
- Level where there is interoperability and from an end user perspective
a good solution that just works with all the heavy lifting behind the
scenes.
- Create convergence so the market can shake out
- Figure out brand later, no business level things on the table today.
Just technology.
- Can't disrupt existing deployed user base, getOpenID.com and
claimID.com are both OpenID providers starting today
- Must be a platform for others to build on
- Convergence ultimately means the practicality of adoption
- Industry must converge before there can be a "big bang"
- Must have a single brand we are all united behind
- Lighter weight than WS-Trust, but also co-exist with the WS-* stack
- Understand how a meta-system can support both card and address based
identity
- Look at how XDI (data exchange layer) can interoperate
- OpenID Authentication is only part of the platform
- Dick to talk about new concept in dix rev3
- Dick would like to know use cases for openid2.0
- Support for direct identity use case
OpenID Authentication 2.0 Overview

Changes Between 1.1 and 2.0
- Completely backward compatible with existing 1.x deployments
- Still tries to deal with the least amount of the problem that it has
to, since it has provisions for extensions
- Minute small changes
o Support for SHA256 in addition to SHA1.  Shows that supporting
multiple hash methods is possible.
o Consistent URL normalization
- Major Feature Changes / Additions
o Can enter either End User Identifier or IdP Identifier to support
directed identity
o Explains how to define and use an extension
* Extra payload during an assertion via POST requests
* Spec needs to address GET and POST arguments with the same name
o Yadis discovery is within the spec
* /signon/2.0 - End User
* /server/2.0 - IdP for directed Identity
* /return_to/2.0 - Relying Party
* Enable single log out
* Browser plugin which can tell you're on a RP
o Identifiers can also be a XRI
- Adds protection against replay attacks with nonces
- Recommends SSL in certain areas
- "Dumb Mode" renamed to "Stateless Mode"

Why is it called Extensions?
- Passing more than just profile data, though the definition of profile
and attribute being used within DIX is extremely broad
- Should it be called something else?  WS stack uses "framework"
- Discovery of extensions is via Yadis

DIX Overview

Signature Verification
1. Take all name/value pairs, treating the entire thing as a string
2. Sort alphabetically
3. Smash into string, with values on the end to protect against always
having the same hash value
4. Signature out of it
- Will look at it dmd01 to make methodology the same between DIX and
OpenID

Allows Identifiers to be Blank
- IdP returns zip code and address, though not an identifier for the End
User
- Instead of generating one time throw away random identifiers
o Allows being recognized in the future if you come back while still
preserving privacy
- Treat the identifier as another attribute that the RP requests

Enabling Protocol via HTML Edits and Not Actual Code
- POST from IdP to RP that map profile data into existing form fields

Rich Clients Will Develop
- Called Identity Agent - Application right now
- Browser plugin or built in for HTTP world
- Secure Chrome discussions
- If you define HTML for login correctly, the plugin can change it to
interact on their behalf
- Supporting evolution of services to replace an existing, how does the
negotiation happen between RP and Identity Agent
- Request information as well as envelope that describes the request,
both have service information
- Will allow putting service requirements within the request to not
reveal all services
- Goal of working both with a plugin and zero foot print
o Relying Party shouldn't have to know if it is a rich client or not,
same interaction in both flows

Attribute Keys are URIs
- Identity Agent is a storage mechanism versus having a set number of
things
- RP can both fetch and store data with the IA
- Must learn how to show data to user as well as let them release it
- Allows rich description (meta-data) of attribute to be stored at its
URI

Relying Party Data Request Attribute Parameters
- Required
- If the IdP already has it, doesn't pester user if not already entered

SAML Relationship
- Messages
- Assertions
o Clear how to move assertions within OpenID or DIX
- Create gradient to move heavier and heavier and increase security
- Reusing SAML request and response by mapping DIX into it (dmd02)
o Looks like SAML to non-SAML people
o Doesn't look like SAML to SAML people
o DIX using SAML abstract messaging
- Different SAML profiles don't interop, this is just another SAML
profile

Fitting This All Together

Compatibility is at library level versus spec level, libraries can
implement multiple specs.  We all would like to see one spec for
authentication.

URL and XRI
- Field which user enters XRI, URL, IdP URL and presses button, it just
works.
- Within DIX since Identifier is an attribute, you could create an
alternate to "Persona URL" which supports an XRI.
- We all see supporting both URLs and XRIs as possible.

Use case of asking for more than one identifier.

Service Discovery
- In OpenID Authentication 2.0 both XRI resolves ending with an XRDS and
URL uses Yadis to point to a XRDS
- DIX uses a method for the RP to request services so that an endpoint
doesn't publicly advertise every service it offers
- Johannes believes we can use Yadis combined with authentication to
restrict services being revealed
o Anonymous XRDS file
o Filtered XRDS file per authentication
- DIX has RP make request with required services, IdP can send a reset
saying it doesn't support some of them and possibly suggests other
comparable service
- Use case of using differing IdPs for different services
o Same Identifier, but points to multiple IdPs
o Given an Identifier, which IdP should the RP talk to for each needed
service
o RP should figure out which IdP to use, which one does each service
best, versus the user having to make a decision
o RP may have business relationship, or trust concerns, with a certain
IdP which effects which one it decides to use
o User may have IdPs in different geographies, RP wants to use one near
them
o If user enters IdP URL then they are directly saying which IdP to use,
entering Identifier infers RP should decide
- Certain capabilities a user is alright being public (auth, basic
profile, etc) and then also things they may not want to make public
- Identity Agent may not actually provide many services, rather stores
attributes.
- DIX has no intention of using Yadis, though their implementations
could certainly consume it.
o Within DIX, they think of using the Identifier to find the IdP.  If
you're typing in the IdP you don't need the service discovery.
o DIX mainly interested in moving data back and forth.
o Don't see a reason why Yadis is needed, while it supports a rich
description of service endpoints, it isn't seen why that is needed.

Focus on convergence through individual components.  80/20 rule of
supporting 80% of all of the use cases.

Seems like we can make authentication work.

Data Transfer
- Not only do I want to auth the user, but also want these attributes
- DIX considers pull use case out of scope
- Use case of RP has an email address which no longer works, how can the
RP request a new email address?
- RP interacts with user out of band, RP needs more info about user, RP
pulls from IdP, IdP does out of band with user, user allows data
exchange, IdP pushes it back to RP
- Separate pieces for protocol/spec for push and pull
- DIX has updates URL for RPs to tell an IdP where to send new
information
- Uses for having the updates URL in both request from RP and XRDS file
on RP
o Updates URL expires, RP switches from Drupal to Plone, so IdP then
looks for a new one in XRDS file
- Common API for pushing blobs to enable profile exchange, email/im, or
sign off
- Single Sign Off isn't really easy

Next face to face could be in Vancouver at the Identity Open Space
event, hosted by Sxip.

All intellectual property created during this meeting is public domain
and royalty free.