non-normative examples for openID Authentication 2.0
Are there any non-normative examples somewhere for openID Authentication 2.0showing what transactions should be taking place at various stages of the protocol, for its major variants? The spec is somewhat confusing at times it is difficult to figure out what I'm doing right or wrong without some good examples. The examples in Appendix A of the spec itself are rather slim. Jason Sachs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
OpenID 3.0
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. * This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies. * ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OpenID 3.0
I'm not sure what the new intellectual property policy means as regards to discussing on the mailing lists. Do I implicitly agree to this policy by posting ideas here? Can someone explain? More info at http://www.mail-archive.com/[EMAIL PROTECTED]/msg2.html Thanks, Hans On 2/1/08, McGovern, James F (HTSC, IT) [EMAIL PROTECTED] 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. * This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies. * ___ 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 3.0
On 02/02/2008, McGovern, James F (HTSC, IT) [EMAIL PROTECTED] 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 I'm not sure what there would be to say in the spec about this: SQL injection is not party of the standard, but rather a feature of some implementations :) 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. The provider authentication policy extension handles half of this already (telling you what checking the OP did). It does not cover the trust issue though, so without a pre-existing trust relationship there is no reason to believe the PAP assertions. The trust side is something that would be interesting to see addressed in future specs. 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. This is already possible with OpenID 2.0: 1. make the Sun OP provide an OP identifier URL that can be used to initiate a directed identity request to authenticate any user of the OP. 2. to authenticate, the Sun employee store would initiate an OpenID request against the URL from (1) rather than asking the user to enter an identity URL. With this setup, the user need not know that they are using OpenID or know what their identity URL is. James. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OpenID 3.0
On 02/02/2008, Kevin Turner [EMAIL PROTECTED] wrote: On Sat, 2008-02-02 at 08:51 +1100, James Henstridge wrote: 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. This is already possible with OpenID 2.0: [snip] This is already possible with OpenID 1.0: Perform discovery on the given identifier. Compare the discovered OP Endpoint to those in your filter. If you do not like what you see, do not proceed. Right. I guess I forgot about that after using directed identity for a few cases just like this. I'd argue that directed identity with a fixed OP URL can provide a nicer workflow for these sort of closed environments though: 1. the RP need not ask for a user name, so all authentication occurs on the OP. 2. If the user is already authenticated to the OP, the user could be authenticated to the RP without having to enter any input (if desired). 3. As mentioned earlier, the user does not need to know their identity URL (or even that they have one) -- they only need ot know the credentials needed to log into the OP. James. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
