Why Connect?

[George Fletcher]

+1 for "coherent identity framework"

So far I've seen existing use cases for....

* distributed federated identity -- OpenID
* protected/delegated API access -- OAuth
* identity attributes -- AX, SREG, Portable Contacts
* 3rd party asserted attributes -- ???
* authentication context -- PAPE
* levels of assurance (including greater than LOA1) -- ICAM profile, PAPE
* mobile support -- Artifact binding
* device/rich client/mobile API access - OAuth
* dynamic legal agreements -- Contract Exchange
* simple, consumer friendly, user experience -- ???
* identity agents (in browser support) -- ???
* trust framework/certification vs whitelisting -- OIX, Kantara working 
group
* support multiple security profiles (public key cryptography) -- ???
* "single" sign out -- ???
* well defined extension mechanism -- OpenID
* multi-hop delegated API access (twitter client -> twitpic use case) -- ???
* simplified discovery -- webfinger
* structured tokens (required for protected discovery <Link>) -- SWT?
* (many more I'm sure... we should add to the list)

As an RP, I have a requirement for identifier backward compatibility 
(basically, a user can't lose their data because the underlying protocol 
changed). Personally, I'm agnostic to the syntax of the protocol.

So my plea to the OpenID community is to take a use case approach and 
then use the appropriate technology to solve these use cases. I can see 
great value to OpenID and OAuth if the v.Next and OpenID Connect 
charters could merge into a "coherent identity framework":)

Thanks,
George

On 5/25/10 12:35 PM, Eran Hammer-Lahav wrote:
> It isn't much different from white listing providers, or using buttons instead of an input box as is common today. Reality is that until we solve the legal issues around trust and liability, the technical solution doesn't matter. Standard machine readable TOS is just the first step. Figuring out the issue of liability is a much bigger issue which is key to any meaningful OpenID adoption.
>
> I view the OpenID Connect proposal as a to-do list for the OAuth community to fill in the missing pieces. For example, OAuth needs to support endpoint discovery, unregistered clients, basic immediate mode and username support, and request and response signatures with either symmetric or asymmetric secrets. These are all *OAuth* elements that should be standardized by the OAuth community in the IETF.
>
> However, putting these components together for a coherent identity framework is what I expect from the OpenID community. It will probably mean that the OpenID WG will need to work closely with the OAuth WG and provide feedback and requirements. But at the end, someone will need to write a spec that puts this all together and that should be the OpenID foundation, even if this spec is not much more than glue.
>
> EHL
>
>    
>> -----Original Message-----
>> From: openid-specs-bounces at lists.openid.net [mailto:openid-specs-
>> bounces at lists.openid.net] On Behalf Of Monroe, Grant
>> Sent: Tuesday, May 25, 2010 5:36 AM
>> To: David Recordon
>> Cc: Joseph Smarr; OpenID Board (public); openid-specs at lists.openid.net
>> Subject: Re: Why Connect?
>>
>>      
>>> Eran Hammer-Lahav (with a +1 from Chuck Mortimore):
>>>        
>>>> My guess is that an OAuth identity layer will not be a good thing for
>>>> OpenID adoption. OAuth providers will get it for free.
>>>>          
>> You know what's not good for adoption? Having to go to 20 different
>> developer portals. Trying to figure out how to create an OAuth application in
>> 20 different ways. Verifying your domain in 20 different ways. Agreeing to 20
>> different terms of service.
>>
>> I know that the OpenID Connect proposal mentions an association step, but
>> if all the major providers wind up requiring preregistration, it is a moot point.
>> My gut is that using OAuth as the base will be very good for a few players,
>> and bad for identity on the whole.
>>
>> --
>> Grant Monroe
>> JanRain, Inc.
>> _______________________________________________
>> specs mailing list
>> specs at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs
>>      
> _______________________________________________
> specs mailing list
> specs at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs
>
>