RE: 2.0 Spec Questions
James, for 3 have you looked at http://openid.net/specs/openid-assertion-quality-extension-1_0-03.html? I don't think it addresses the specific point you brought up, though may be the right place to do it. --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of James McGovern Sent: Sunday, January 21, 2007 4:49 PM To: specs@openid.net Subject: 2.0 Spec Questions Sensitivity: Confidential 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. 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? 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? 4. Some portions of the spec are heavily coupled to PKI. How should growing users of IBE think of this? ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: 2.0 Spec Questions
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? ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
2.0 Spec Questions
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. 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? 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? 4. Some portions of the spec are heavily coupled to PKI. How should growing users of IBE think of this? ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
