RE: OpenID 3.0

[McGovern, James F (HTSC, IT)]

 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, BB&T 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/ma

Re: OpenID 3.0

[NISHITANI Masaki]

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

[Paul Madsen]

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 by return e-mail, delete this communication and
> destroy all copies.
> *
>
> ___
> specs mailing list
> specs@openid.net
> http://openid.net/mailman/listinfo/specs
>
>
>   

-- 
Paul Madsen e:paulmadsen @ ntt-at.com
NTT p:613-482-0432
m:613-282-8647
aim:PaulMdsn5
web:connectid.blogspot.com 

___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

RE: OpenID 3.0

[McGovern, James F (HTSC, IT)]

 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

[NISHITANI Masaki]

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

[David Recordon]

+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

[Eddy Nigg (StartCom Ltd.)]

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. 
Jabber: [EMAIL PROTECTED] 
Blog:   Join the Revolution! 
Phone:  +1.213.341.0390


___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: OpenID 3.0

[Eddy Nigg (StartCom Ltd.)]

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. 
Jabber: [EMAIL PROTECTED] 
Blog:   Join the Revolution! 
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)]

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

[Nat Sakimura]

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

[Johannes Ernst]

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

[James Henstridge]

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

[Eddy Nigg (StartCom Ltd.)]

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. 
Jabber: [EMAIL PROTECTED] 
Blog:   Join the Revolution! 
Phone:  +1.213.341.0390


___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: OpenID 3.0

[James Henstridge]

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

Re: OpenID 3.0

[Martin Atkins]

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

Re: OpenID 3.0

[Eddy Nigg (StartCom Ltd.)]

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?


James Henstridge wrote:

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.
  

--
Regards 


Signer: Eddy Nigg, StartCom Ltd. 
Jabber: [EMAIL PROTECTED] 
Blog:   Join the Revolution! 
Phone:  +1.213.341.0390




smime.p7s
Description: S/MIME Cryptographic Signature
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: OpenID 3.0

[James Henstridge]

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

Re: OpenID 3.0

[Kevin Turner]

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.


___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: OpenID 3.0

[James Henstridge]

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

[Hans Granqvist]

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