OpenID 3.0

[Nat Sakimura]

Hi.

For

> 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. 

like it was mentioned before PAPE does some job, and AQE does some other. 
Of course, that is only the claim that OP makes, so there has to be some kind of trust framework, where I belive that reputation comes in. 

> 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. 

Simple way of doing this is white list. Many does this already. 
More dynamic one would use Reputation Service. 

Reputation Service would be another (sort of ) extention, IMHO. 

On the reputation, I wrote a bit on my blog, so you may want to read it as well. 

http://www.sakimura.org/en/modules/wordpress/index.php?p=30

Re: OpenID 3.0

While we were writing (are still writing) OpenID Trusted data Exchange 
(TX) proposal, we started to feel that if we introduce Reputation 
Service appropreately, we can skip the association and 
check_authentication entirely. If this kind of change would make the 
protocol faster and more secure, we perhaps can start considering it in 
the core spec., but otherwise, they should be done as extension spec. 
Rule of the thumb perhaps is that unless we need to touch / change the 
basic flow of the core protocol, we do not need to go to 3.0.

Regards,

=nat

Johannes Ernst wrote:
> 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 at openid.net
>> http://openid.net/mailman/listinfo/specs
>>     
>
> _______________________________________________
> specs mailing list
> specs at openid.net
> http://openid.net/mailman/listinfo/specs
>