PAPE and NIST level policies.
Hi. PAPE responses have the ability to send NIST levels used for authentication. It would be useful to add these levels as standardized request policy URLs to the spec so that the RP could send hints on wished authentication strength to the OP. BTW, why is there a specific nist_auth_level parameter which is directly tied to one standards institute yet the 'core' of PAPE, policies, don't really define anything except vague 'policies to be specified elsewhere' ? -- Martin Paljak http://martin.paljak.pri.ee +372.515.6495 ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: PAPE and NIST level policies.
Right. I was lazy and google directed me to 1.0-02 as the first response ... m. On 25.11.2008, at 12:03, Nat wrote: The proposal on the table has generalized NIST thing, I believe. As to the upstream hint is concerned, I think it is a good idea but it was out of scope of the current WG. It belongs to the future spec I guess. [EMAIL PROTECTED] via iPhone On 2008/11/25, at 18:10, Martin Paljak [EMAIL PROTECTED] wrote: Hi. PAPE responses have the ability to send NIST levels used for authentication. It would be useful to add these levels as standardized request policy URLs to the spec so that the RP could send hints on wished authentication strength to the OP. BTW, why is there a specific nist_auth_level parameter which is directly tied to one standards institute yet the 'core' of PAPE, policies, don't really define anything except vague 'policies to be specified elsewhere' ? -- Martin Paljak http://martin.paljak.pri.ee +372.515.6495 ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs -- Martin Paljak http://martin.paljak.pri.ee +372.515.6495 ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: PAPE and NIST level policies.
The proposal on the table has generalized NIST thing, I believe. As to the upstream hint is concerned, I think it is a good idea but it was out of scope of the current WG. It belongs to the future spec I guess. [EMAIL PROTECTED] via iPhone On 2008/11/25, at 18:10, Martin Paljak [EMAIL PROTECTED] wrote: Hi. PAPE responses have the ability to send NIST levels used for authentication. It would be useful to add these levels as standardized request policy URLs to the spec so that the RP could send hints on wished authentication strength to the OP. BTW, why is there a specific nist_auth_level parameter which is directly tied to one standards institute yet the 'core' of PAPE, policies, don't really define anything except vague 'policies to be specified elsewhere' ? -- Martin Paljak http://martin.paljak.pri.ee +372.515.6495 ___ 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: PAPE and NIST level policies.
Yeah, the latest draft is at http://openid.net/specs/openid-provider-authentication-policy-extension-1_0-05.html . On Nov 25, 2008, at 2:21 AM, Martin Paljak wrote: Right. I was lazy and google directed me to 1.0-02 as the first response ... m. On 25.11.2008, at 12:03, Nat wrote: The proposal on the table has generalized NIST thing, I believe. As to the upstream hint is concerned, I think it is a good idea but it was out of scope of the current WG. It belongs to the future spec I guess. [EMAIL PROTECTED] via iPhone On 2008/11/25, at 18:10, Martin Paljak [EMAIL PROTECTED] wrote: Hi. PAPE responses have the ability to send NIST levels used for authentication. It would be useful to add these levels as standardized request policy URLs to the spec so that the RP could send hints on wished authentication strength to the OP. BTW, why is there a specific nist_auth_level parameter which is directly tied to one standards institute yet the 'core' of PAPE, policies, don't really define anything except vague 'policies to be specified elsewhere' ? -- Martin Paljak http://martin.paljak.pri.ee +372.515.6495 ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs -- Martin Paljak http://martin.paljak.pri.ee +372.515.6495 ___ 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: OpenID/OAuth hybrid - discovery
I really don't think we're disagreeing here. There should and will be more places to discover OAuth endpoints, etc. But that's outside the scope of this spec. All we're saying in this spec is that if discovery starts from a user-supplied OpenID (not from a OAuth-protected resource, btw, which is the use case you're describing below), there is a way for the OP to signal to the RP whether it might want to try sending the OAuth extension parameters along with the auth request. There is no extra HTTP transaction. Dirk. On Mon, Nov 24, 2008 at 11:26 PM, Martin Atkins [EMAIL PROTECTED]wrote: Dirk Balfanz wrote: We're defining an OpenID extension. Consumer will want to know whether or not a given endpoint speaks that extension. That's all it's doing - just like AX or PAPE have a section on discoverability. It also gives consumers a way to look for the combined OpenID/OAuth endpoint (assuming that one day we'll have these massive XRD documents advertising all sorts of things - OAuth request token endpoints, portable contact endpoints, etc.). I guess I'm assuming that the OAuth service saying use that OpenID provider for hybrid OpenID/OAuth implies that the OpenID Provider supports the extension. However, I guess the following flow could arise: * User does something that requires OAuth. * Consumer does OAuth Discovery (to be defined) and determines, amongst other things, the URL of the OpenID Provider that will do the combined OpenID/OAuth bit. * Consumer does discovery on the OpenID Provider and determines that it doesn't actually support the extension. * Consumer falls back on the non-combined flow, or just tells the user that the service provider is broken. While it's nice to fail early in this case, the consumer still needs to deal with a bunch of post-authorization failure cases: * Provider claimed to support the extension but didn't actually return anything. * Provider claimed to support the extension but the approved request token doesn't actually work for some reason. * Provider claimed to support the extension but it turns out it doesn't support this particular sort of request token. * ... In most cases, the implication from the OAuth discovery step will be enough and everything will work out. I'm not sure whether failing early in this one (unlikely) error case is worth the extra HTTP transaction(s) to find out whether the provider really supports the extension. It'd be more efficient to just send a request to the OpenID provider with the extension arguments and see if you get back a response. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]
Some more feedback: The first sentence in the Abstract should say describes instead of describe. The phrase OpenID OAuth Extension is not consistently capitalized in the spec. For instance, it's capitalized in the first sentence in section 3, but extension is lowercase in section 4. Sections 5 and 8 call it the OAuth extension, rather than the OpenID OAuth Extension. The second word in Section 7, Requesting should be all lowercase. In Section 7, the phrase this extension can be used to request that the end user authorize an OAuth token should probably be clarified to say that the user is authorizing an OAuth Access token. In the last sentence of Section 8, the phrase SHOULD not should be in all caps, SHOULD NOT. I recommend that the phrase Combined Consumer be used instead of simply Consumer everywhere in the spec. The third paragraph in section 9, and the description for OAuth token secret in Section 10 still say Consumer. In Section 10, is the Access Token endpoint discoverable? I guess that's out of scope for this spec. In Section 10, and perhaps also in Section 12, the spec should mention that because the hybrid protocol does not have a request token secret, and because the user is never required to manually type in the request token (unlike in OAuth), the hybrid Request Token probably should be longer and harder to guess than the standard OAuth Request Token. At least for our implementation, I'm thinking that the hybrid RT == OAuth's RT+RTSecret. I think the spec is getting pretty close. thanks Allen Dirk Balfanz wrote: Otherwise, the spec is looking pretty good! Great! We're officially calling it Draft 1 now :-) (the previous version was Draft 0). ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
