2.0 Spec Questions

[Dick Hardt]

On 21-Jan-07, at 4:48 PM, James McGovern wrote:

> Several questions after reading the 2.0 spec - draft 11.
>
> 1. The definition of realm if I am reading it correctly could be  
> problematic
> in large enterprises. For example, if one were using a web access  
> management
> product, they would have the ability to define a realm in terms of  
> a listing
> of discrete hosts that may or may not fit a URL pattern matching  
> approach.
> For example, I could have a demographic called consumers who could  
> access
> hosts such as http://myconsumer.example.com ,
> http://printstatements.example.com, http://paybills.example.com  
> Likewise
> another demographic called Business Partner may have a different  
> set of
> hosts they can interact with.

The motivation of the realm is to deal with web sites where there are  
many host names, but really one site -- LiveJournal being the  
motivating use case, as well as being where OpenID got its start.  
Each blog has a separate hostname:

dick.livejournal.com
brad.livejournal.com

Since different blogs have different hostnames, but a user thinks of  
them all as being lLiveJournal, so being able to have a realm of:

	*.livejournal.com

>
> 2. In terms of checking the nonce, can we recommend that a deployment
> practice should be to use the NTP protocol and point to clocks of a  
> certain
> stratum? Likewise, would it be a good idea if an association could  
> indicate
> how much skew it would accept before rejecting?

The date-time stamp in the nonce is really to assist the RP in  
knowing that it can discard a message if it is older then a x period  
rather then having to hold every nonce received. I don't know how  
much skew happens out in the wild these days, but perhaps we could  
get an idea of what that is and then recommend how long the RP should  
keep a nonce before discarding?

>
> 3. In terms of an extension, should an OP be able to indicate when  
> reauth
> may be required so the user doesn't assume that if they  
> authenticate once
> they are always good?

AuthN is for the benefit of the RP.  While one view might be that the  
OP should be able to dictate how long the AuthN is good for, once  
used, it is really the RP that is determining if it is the same user.

I think the more important consideration is the RP wanting to get the  
OP to do AuthN for the user instead of using a cached AuthN. I wanted  
to put it in the spec, but the decision was that it was better in an  
extension.

>
> 4. Some portions of the spec are heavily coupled to PKI. How should  
> growing
> users of IBE think of this?

Besides recommending sites use TLS, I don't see the PKI coupling you  
are referring to. Would you elaborate?