+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: [email protected] [mailto:openid-specs-
[email protected]] On Behalf Of Monroe, Grant
Sent: Tuesday, May 25, 2010 5:36 AM
To: David Recordon
Cc: Joseph Smarr; OpenID Board (public); [email protected]
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
[email protected]
http://lists.openid.net/mailman/listinfo/openid-specs
_______________________________________________
specs mailing list
[email protected]
http://lists.openid.net/mailman/listinfo/openid-specs
_______________________________________________
specs mailing list
[email protected]
http://lists.openid.net/mailman/listinfo/openid-specs
