RE: OpenID 3.0
The answer of whether an insurance agency would be the OP is it depends. Generally speaking, there are very large insurance agencies and brokers such as Marsh, BBT that have 40K employees where they would probably stand up their own OP where as the small agency with three people none of which are IT wouldn't be. In many domains, whether it is insurance agent, travel agent, etc they may also use an application service provider (ASP) to host much of their core business systems. At some level, it would make sense for these types of providers to become OP. Generally speaking, insurance agents can do business with a multitude of carriers where the OP would need to assert things such as agent X is licensed to sell auto insurance in Texas and life insurance in California which don't fit the typical name/value pair structure and feels more XACML like. -Original Message- From: Paul Madsen [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 26, 2008 1:23 PM To: McGovern, James F (HTSC, IT) Cc: specs@openid.net Subject: Re: OpenID 3.0 in a B2B case, would not the insurance agency be the OP, and its identity carried through the relevant assertion fields? As Masaki-san points out, the RP can base its authorization decision on any number of factors - some of which might be carried through OpenID, some not. In this sense, OpenID is already 'converged' with authorization, as an RP already bases its authz decision on the asserted identifier. Allowing for the protocol to carry other attributes that might also feed into the decision is just an enhancement. Theoretically possible would be for the OP assertion to actually carry an 'authorization statement' expressing some set of privileges the user should enjoy at the RP (and that the RP would respect). Possible, but weird because of the implied loss of sovereignty for the RP. paul McGovern, James F (HTSC, IT) wrote: If you were going to use OpenID in a B2B scenario where an insurance agent want to access an insurance carriers web site, the identity provider would need to not only pass the identity of the agent but also the insurance agency, the insurance agent is employed by. -Original Message- From: NISHITANI Masaki [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 26, 2008 1:10 AM To: McGovern, James F (HTSC, IT) Cc: specs@openid.net Subject: Re: OpenID 3.0 Let me confirm a point. On #1, do you mean to enforce OpenID to control the identity-holders are permitted to access what kind of content or service on RP or provide some kind of help making RP's decision easier? I feel it is natural for RP to do access-control be itself, but on the other hand, any information which describes what kind of person the accessing web-user is, will be welcome for RPs such as gender, age or any kind of attributes. McGovern, James F 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 ** *** 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
RE: OpenID 3.0
If you were going to use OpenID in a B2B scenario where an insurance agent want to access an insurance carriers web site, the identity provider would need to not only pass the identity of the agent but also the insurance agency, the insurance agent is employed by. -Original Message- From: NISHITANI Masaki [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 26, 2008 1:10 AM To: McGovern, James F (HTSC, IT) Cc: specs@openid.net Subject: Re: OpenID 3.0 Let me confirm a point. On #1, do you mean to enforce OpenID to control the identity-holders are permitted to access what kind of content or service on RP or provide some kind of help making RP's decision easier? I feel it is natural for RP to do access-control be itself, but on the other hand, any information which describes what kind of person the accessing web-user is, will be welcome for RPs such as gender, age or any kind of attributes. McGovern, James F 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 * 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
As you said, it sound natural for me to use end-user (identity holder)'s attribute delivered via SREG or AX as a factor to decide RP's behavior. Such as provides a financial counseling service only for users who discloses their amount of incomes to the RP. But in such case, there will be a room to fill by proceeding the specs of OpenID to the next step. One of the most major cases of an authorization with attributes delivered by OpenID is a age confirmation on online liquor stores. But I do not think current OpenID is not enough to fit such 'serious' case. Age confirmation does not work if the OP is not trustworthy enough though OpenID does not support any method to verify OPs. I feel, just as talked in other trees, implementing support for reputation services or any other effort to bring more 'trustworthy transaction' into OpenID will come to the place. in a B2B case, would not the insurance agency be the OP, and its identity carried through the relevant assertion fields? As Masaki-san points out, the RP can base its authorization decision on any number of factors - some of which might be carried through OpenID, some not. In this sense, OpenID is already 'converged' with authorization, as an RP already bases its authz decision on the asserted identifier. Allowing for the protocol to carry other attributes that might also feed into the decision is just an enhancement. Theoretically possible would be for the OP assertion to actually carry an 'authorization statement' expressing some set of privileges the user should enjoy at the RP (and that the RP would respect). Possible, but weird because of the implied loss of sovereignty for the RP. paul McGovern, James F (HTSC, IT) wrote: If you were going to use OpenID in a B2B scenario where an insurance agent want to access an insurance carriers web site, the identity provider would need to not only pass the identity of the agent but also the insurance agency, the insurance agent is employed by. -Original Message- From: NISHITANI Masaki [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 26, 2008 1:10 AM To: McGovern, James F (HTSC, IT) Cc: specs@openid.net Subject: Re: OpenID 3.0 Let me confirm a point. On #1, do you mean to enforce OpenID to control the identity-holders are permitted to access what kind of content or service on RP or provide some kind of help making RP's decision easier? I feel it is natural for RP to do access-control be itself, but on the other hand, any information which describes what kind of person the accessing web-user is, will be welcome for RPs such as gender, age or any kind of attributes. McGovern, James F wrote: ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OpenID 3.0
Let me confirm a point. On #1, do you mean to enforce OpenID to control the identity-holders are permitted to access what kind of content or service on RP or provide some kind of help making RP's decision easier? I feel it is natural for RP to do access-control be itself, but on the other hand, any information which describes what kind of person the accessing web-user is, will be welcome for RPs such as gender, age or any kind of attributes. McGovern, James F 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
+1. Let's get 2.0 deployed and figure out what it might be lacking before just starting on 3.0. On Feb 3, 2008, at 11:05 PM, 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@openid.net http://openid.net/mailman/listinfo/specs ___ 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
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@openid.net http://openid.net/mailman/listinfo/specs ___ 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
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 :) [JFM] I agree that many of the ways that have been implemented to date are insecure and that many of the implementors would be well served by running their code bases through tools such as Ouncelabs (www.ouncelabs.com) Coverity (www.coverity.com) and others. I also believe that if the spec further defined what an identifier could look like, implementors could write validation code to make more secure. If an identifier can be anything then you can't really strongly validate. 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. [JFM] Strongly agree here. OpenID needs to be used for more than just blog sites and free email providers. If businesses who conduct commerce in a B2B scenario were to embrace, the notion of trust needs to be discussed. Likewise, it seems as if many folks here are either consultants or software vendors and having a strong enterprise story could put money into your pockets. 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. [JFM] I think the scenario I mentioned was an example and not meant to be 1 to 1. Maybe you could tell me how it would work if I had more than one Sun, say Oracle, IBM, BEA and CA. * 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
McGovern, James F (HTSC, IT) wrote: 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. Right! The trust side is something that would be interesting to see addressed in future specs. It has been brought up various times here without any success. Either the OpenID designers have something very specific in mind for the future in that respect (and which will come from outside the specs) and/or the i-names/i-numbers will be the only game in town at some point? Not sure, just guessing... [JFM] Strongly agree here. OpenID needs to be used for more than just blog sites and free email providers. If businesses who conduct commerce in a B2B scenario were to embrace, the notion of trust needs to be discussed. Absolutely agree in both accounts here too. OpenID doesn't want to address this issue (even it should so in some form). Even a watered-down federation of OPs for white lists in order to tackle spam was suggested previously... The only way to do that, as you indicate below, is by hand-picking the OPs you trust. This can be one or many... 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. -- Regards Signer: Eddy Nigg, StartCom Ltd. http://www.startcom.org Jabber: [EMAIL PROTECTED] xmpp:[EMAIL PROTECTED] Blog: Join the Revolution! http://blog.startcom.org Phone: +1.213.341.0390 ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OpenID 3.0
McGovern, James F (HTSC, IT) wrote: One of the scenarios that reputation would need to consider is the security of all channels. For example, in my role I may deem that I will only trust interactions that occurred 100% over SSL. If someone specified an HTTP Open ID (e.g. http://james.myopenid.com/) and not (https://james.moresecureopenid.com) then I can ignore the entire flow. Not entirely correct. The OpenID could be even entered as james.myopenid.com, but the interaction with the OpenID server can be in SSL mode, plus the OP returns openid.identity = https://james.myopenid.com . At this stage the RP can make a decision, not before I think. -- Regards Signer: Eddy Nigg, StartCom Ltd. http://www.startcom.org Jabber: [EMAIL PROTECTED] xmpp:[EMAIL PROTECTED] Blog: Join the Revolution! http://blog.startcom.org Phone: +1.213.341.0390 ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
OpenID 3.0
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. This is noble to think this way but the odds of this becoming reality are very slim. There are always new attack vectors and this protocol needs to change to stay secure even if it breaks backward compatibility. I think the issue of whitelisting not only belongs on the side of the relying party but also allowing each user of OpenID to indicate whitelists in terms of how they will want their OpenID leveraged. This should be supported by the identity provider. This is more than simply putting the user in the middle. One of the scenarios that reputation would need to consider is the security of all channels. For example, in my role I may deem that I will only trust interactions that occurred 100% over SSL. If someone specified an HTTP Open ID (e.g. http://james.myopenid.com/) and not (https://james.moresecureopenid.com) then I can ignore the entire flow. Reputation works only if there are certain trust cues of which things such as EV SSL could be one. As far as the LDAP thread, has anyone approached Microsoft regarding turning Active Directory into an OpenID provider? * 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
James Henstridge wrote: Thanks for your reply... When used in directed identity mode, the OP can pick the identity: http://openid.net/specs/openid-authentication-2_0.html#responding_to_authentication Of course, the OP is restricted to returning identities that it is authoritative for. This is what allows any yahoo user to enter yahoo.com as their OpenID identifier while still letting RPs tell them apart. Right, that's what I thought...What does it have to return however? Is it enough to return [openid_identity] = https://somenick.domain.com/, [openid_claimed_id] = https://domain.com/ ? My point was that in cases where you do want to limit things to a single OP, it is worth considering this mode, since it does not require the user to enter any credentials (username or password) at the RP site. Yes, that is rather easy. Somewhat more tricky gets when you want to use a group of providers and ban certain providers. All doable, but not standardized yete.g. white/black lists. -- Regards Signer: Eddy Nigg, StartCom Ltd. http://www.startcom.org Jabber: [EMAIL PROTECTED] xmpp:[EMAIL PROTECTED] Blog: Join the Revolution! http://blog.startcom.org Phone: +1.213.341.0390 ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OpenID 3.0
On 04/02/2008, Eddy Nigg (StartCom Ltd.) [EMAIL PROTECTED] wrote: James Henstridge wrote: Of course, the OP is restricted to returning identities that it is authoritative for. This is what allows any yahoo user to enter yahoo.com as their OpenID identifier while still letting RPs tell them apart. Right, that's what I thought...What does it have to return however? Is it enough to return [openid_identity] = https://somenick.domain.com/, [openid_claimed_id] = https://domain.com/ ? That is possible provided that performing discovery on https://domain.com/ gives you https://somenick.domain.com/ as the OP local identifier and uses the given OP. When selecting an identifier, the OP chooses both the local identifier (openid.identifier) and claimed ID (openid.claimed_id). My point was that in cases where you do want to limit things to a single OP, it is worth considering this mode, since it does not require the user to enter any credentials (username or password) at the RP site. Yes, that is rather easy. Somewhat more tricky gets when you want to use a group of providers and ban certain providers. All doable, but not standardized yete.g. white/black lists. As Kevin said, you can always apply that kind of policy at the end of authentication process. You can do that with either OpenID 1.x or 2.0. James. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OpenID 3.0
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@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, Eddy Nigg (StartCom Ltd.) [EMAIL PROTECTED] wrote: Yes, I also wonder why the IDP can't just return the ID. As of now I think it's two steps for this, with the RP explicit requesting it? Or am I wrong with that? When used in directed identity mode, the OP can pick the identity: http://openid.net/specs/openid-authentication-2_0.html#responding_to_authentication Of course, the OP is restricted to returning identities that it is authoritative for. This is what allows any yahoo user to enter yahoo.com as their OpenID identifier while still letting RPs tell them apart. My point was that in cases where you do want to limit things to a single OP, it is worth considering this mode, since it does not require the user to enter any credentials (username or password) at the RP site. James. ___ 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
