Re: OpenID 3.0

2008-02-03 Thread Eddy Nigg (StartCom Ltd.)

James Henstridge wrote:

Thanks for your reply...

When used in directed identity mode, the OP can pick the identity:


http://openid.net/specs/openid-authentication-2_0.html#responding_to_authentication

Of course, the OP is restricted to returning identities that it is
authoritative for.  This is what allows any yahoo user to enter
yahoo.com as their OpenID identifier while still letting RPs tell
them apart.
  
Right, that's what I thought...What does it have to return however? Is 
it enough to return [openid_identity] = https://somenick.domain.com/, 
[openid_claimed_id] = https://domain.com/ ?

My point was that in cases where you do want to limit things to a
single OP, it is worth considering this mode, since it does not
require the user to enter any credentials (username or password) at
the RP site.
Yes, that is rather easy. Somewhat more tricky gets when you want to use 
a group of providers and ban certain providers. All doable, but not 
standardized yete.g. white/black lists.



--
Regards 


Signer: Eddy Nigg, StartCom Ltd. http://www.startcom.org
Jabber: [EMAIL PROTECTED] xmpp:[EMAIL PROTECTED]
Blog:   Join the Revolution! http://blog.startcom.org
Phone:  +1.213.341.0390


___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs


Re: OpenID 3.0

2008-02-03 Thread James Henstridge
On 04/02/2008, Eddy Nigg (StartCom Ltd.) [EMAIL PROTECTED] wrote:
  James Henstridge wrote:
  Of course, the OP is restricted to returning identities that it is
  authoritative for.  This is what allows any yahoo user to enter
  yahoo.com as their OpenID identifier while still letting RPs tell
  them apart.

 Right, that's what I thought...What does it have to return however?
 Is it enough to return [openid_identity] = https://somenick.domain.com/,
 [openid_claimed_id] = https://domain.com/ ?

That is possible provided that performing discovery on
https://domain.com/ gives you https://somenick.domain.com/ as the OP
local identifier and uses the given OP.

When selecting an identifier, the OP chooses both the local identifier
(openid.identifier) and claimed ID (openid.claimed_id).


  My point was that in cases where you do want to limit things to a
  single OP, it is worth considering this mode, since it does not
  require the user to enter any credentials (username or password) at
  the RP site.

 Yes, that is rather easy. Somewhat more tricky gets when you want to
 use a group of providers and ban certain providers. All doable, but not
 standardized yete.g. white/black lists.

As Kevin said, you can always apply that kind of policy at the end of
authentication process.  You can do that with either OpenID 1.x or
2.0.

James.
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs


Re: OpenID 3.0

2008-02-03 Thread Johannes Ernst
Amen. Let's build (optional) extensions, and only if that absolutely  
does not work for an essential feature, meekly suggest that the  
smallest possible set of changes be made to an existing spec.

Note that any term such as OpenID 3.0 is mostly a marketing /  
branding term, just like OpenID 2.0. What it really means is what  
underlying specs are being packaged into a larger term.

On Feb 2, 2008, at 2:36, Martin Atkins wrote:


 I apologise that this message doesn't directly address any of the  
 points
 you've made, but others have been doing that.

 I just want to make a general point:
 In my opinion, we should resist the urge to start specing OpenID 3.0
 (aka OpenID vNext) and try to do everything else that needs to be done
 with extensions now. OpenID 2.0 has laid the framework for  
 decentralized
 extensibility, so it should now be much easier to work within that
 framework.

 If it turns out that some particular feature absolutely can't be done
 without making a new Authentication spec release then so be it, but
 ideally I think we want 2.0 to be stable for many years to come to  
 avoid
 repeating all of the current pain of incompatible versions and the  
 poor
 user experience that creates.


 McGovern, James F (HTSC, IT) wrote:
 Figured I would ask if anyone is interested in brainstorming the next
 version of OpenID and how it can be used in Enterprise B2B settings  
 and
 not solely focusing on consumerish interactions. Some things that I
 would like to see in the next version are:

 1. A discussion on how AuthZ can converge with OpenID
 2. Modeling of relationships
 3. Not allowing an OpenID to be a vector for SQL Injection and  
 putting
 something around what it should look like
 4. A way to indicate to the relying party what level of  
 authentication
 has occurred such as did the OP check a password, how did it  
 validate a
 user. Without this, there is no way that a trust model could be
 established in a credible way.

 5. A way for OpenID relying parties to filter out Ops. In a business
 scenario, if I run the Sun employee store, I may only want the Sun  
 OP to
 talk with me.

 ___
 specs mailing list
 specs@openid.net
 http://openid.net/mailman/listinfo/specs

___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs