user centric delegation vs portability: LRDD : competing threats: the consumer's fear hypothesis

[Peter Williams]

I found the writeup at http://hueniverse.com/2009/09/openid-and-lrdd/ convincing, technically. It moved the whole set of technical delegation issues forward. It told a story. It was well written.

A. It reminded me of what Ping Identity once proposed for dynamically-sharing SAML metadata between IDPs and (affiliations of) SP:  use a url-factory rule to deduce a URI from a domain name, get metadata from said URL, and apply https/domain-cert controls to test for a saml entities authority... to make assertions for that domain name. Optionally, sign the metadata (much as one optionally signs XRDs). All Pretty obvious stuff ...but effective.

B. It reminded me of the leap forward of myopenid, when hosting outouurced OPs via OPX (which uses DNS control principles to enable domain admins to prove the delegated domain is authorizing the outsourcer to speak for it).

C. And, it reminded me of openid2, in that there are various flow fallbacks. These allows communities to choose different flows (and thereby address different players issue sets) when delegating and locating providers.

What I didnt like what the bias I heard throughout the writeup - concerning the criteria I described in C.

Unlike the openid communities traditional mission (empower users, and give them control over their data and names), there was a fear message at the heart of it: focus on all that which COULD go wrong. And into that fear rides the fearless knight on a white horse... the OP.

The fear said, users are easily duped and cannot in any case be trusted to get it right - unlike the corporate CISO in whom we must trust. (Peter is a CISO, by the way). Furthermore, we will bias the fallbacks so corporate CIOs can control, before users control. If this was law, folks just coded their bias in favor of the CIO and against the user/subscriber - through the formulation of the legal presumptions.

Now, this bias may well be fine (if your audience is corporate buyers of outsourced apps, leveraging openid protocols to get login sessions and attributes). And, perhaps that is who the vendor is pitching its LRPP technology to .

But, surely, the openid movement more generally needs to be focussed more widely than only corporate sales -it also has consumer interests to consider. If it fails here, it will risk falling into the pit that SAML fell into - and fail to stay current with the larger currents of the web itself. Historically (in the years before openid challenged SAML), every corporate SAML link took a year, cost a million, was the bane of the CIO life, and noone did two if they could avoid it.

Now, as oft associated with the Facebook brand, there are interplays between the corporate control and consumer rights - particularly over data ownership and identity control isues. And some mega-brands do better than others in getting the balance right (and some actively hamper the user when dis-associating from the brand, once things go sour). Some brands infamously create explicit exit barriers (preventing you from exporting your contacts to a file, say, or impose legal controls that limit just who you may (NOT) choose to also work with).

When considering whether LRPP MAY be right for openid movement, we must reflect that the openid movement is -or at least WAS - in the middle of these issues, and took a position. It traditionally allowed for identifier portablity and data rights. If you were to lose rights of access at an OP (paypal dumps peter for violating service rule X) ... delegation ensured that this 1 OP's suspension of Peter made no difference to Peter's private life and Peter's relationship with RPs (becuase the protocols automatically fell back on the next OP to which peter had delegated YOUR name). Peter either could take such pre-cautions, or not - depending on his needs.

What Im hearing in the LRPP story is not consistent with the original openid user-centric story - targeting social networks (vs corporate application outsourcing). The fear line seems to be implicitely denying the legitimacy of user centric identity. In its marketing line, it seems to be saying that: its far more important for consumers  to be free of fear, than be free of a provider (when the relationship goes sour).

Interesting changes going on in this movement!

[John Bradley-9]

Peter,

LRDD discovery will not remove the ability for users to delegate there  
openID provider service to whomever they like.

That isn't to say that all the providers will support delegation.  
That is a separate issue.

However there is no proven business model for users controlling there  
own identifier.   Users in general opted for free services that don't  
allow for portability, rather than for the XRI model that allowed for  
portability and independence from the faustian bargain people have  
struck with the social networks.

There were a lot of us who put a lot of effort into making openID user  
centric rather than OP centric.  At the end of the day people didn't  
care.

Perhaps one day they will.

Nothing in personal delegation has been removed if you have your own  
domain.
Yes users who don't have there own domain may loose the ability to  
delegate if they don't control the domain.  That was a risk they  
always ran.

What has been added is the ability to delegate discovery of meta-data  
for an entire domain.

So SME do gain something.

Perhaps XRI based iBrokers will make a comeback or Chi.mp like  
services for hosting personal XRD with email or URL identifiers.   I  
think they are a important option for people but I am not holding my  
breath.

John B.




On 2009-1025, at 7:57 PM, Peter Williams wrote:

>
> I found the writeup at http://hueniverse.com/2009/09/openid-and-lrdd/
> convincing, technically. It moved the whole set of technical  
> delegation
> issues forward. It told a story. It was well written.
>
> A. It reminded me of what Ping Identity once proposed for
> dynamically-sharing SAML metadata between IDPs and (affiliations of)  
> SP:
> use a url-factory rule to deduce a URI from a domain name, get  
> metadata from
> said URL, and apply https/domain-cert controls to test for a saml  
> entities
> authority... to make assertions for that domain name. Optionally,  
> sign the
> metadata (much as one optionally signs XRDs). All Pretty obvious stuff
> ...but effective.
>
> B. It reminded me of the leap forward of myopenid, when hosting  
> outouurced
> OPs via OPX (which uses DNS control principles to enable domain  
> admins to
> prove the delegated domain is authorizing the outsourcer to speak  
> for it).
>
> C. And, it reminded me of openid2, in that there are various flow  
> fallbacks.
> These allows communities to choose different flows (and thereby  
> address
> different players issue sets) when delegating and locating providers.
>
> What I didnt like what the bias I heard throughout the writeup -  
> concerning
> the criteria I described in C.
>
> Unlike the openid communities traditional mission (empower users,  
> and give
> them control over their data and names), there was a fear message at  
> the
> heart of it: focus on all that which COULD go wrong. And into that  
> fear
> rides the fearless knight on a white horse... the OP.
>
> The fear said, users are easily duped and cannot in any case be  
> trusted to
> get it right - unlike the corporate CISO in whom we must trust.  
> (Peter is a
> CISO, by the way). Furthermore, we will bias the fallbacks so  
> corporate CIOs
> can control, before users control. If this was law, folks just coded  
> their
> bias in favor of the CIO and against the user/subscriber - through the
> formulation of the legal presumptions.
>
> Now, this bias may well be fine (if your audience is corporate  
> buyers of
> outsourced apps, leveraging openid protocols to get login sessions and
> attributes). And, perhaps that is who the vendor is pitching its LRPP
> technology to .
>
> But, surely, the openid movement more generally needs to be focussed  
> more
> widely than only corporate sales -it also has consumer interests to
> consider. If it fails here, it will risk falling into the pit that  
> SAML fell
> into - and fail to stay current with the larger currents of the web  
> itself.
> Historically (in the years before openid challenged SAML), every  
> corporate
> SAML link took a year, cost a million, was the bane of the CIO life,  
> and
> noone did two if they could avoid it.
>
> Now, as oft associated with the Facebook brand, there are interplays  
> between
> the corporate control and consumer rights - particularly over data  
> ownership
> and identity control isues. And some mega-brands do better than  
> others in
> getting the balance right (and some actively hamper the user when
> dis-associating from the brand, once things go sour). Some brands  
> infamously
> create explicit exit barriers (preventing you from exporting your  
> contacts
> to a file, say, or impose legal controls that limit just who you may  
> (NOT)
> choose to also work with).
>
> When considering whether LRPP MAY be right for openid movement, we  
> must
> reflect that the openid movement is -or at least WAS - in the middle  
> of
> these issues, and took a position. It traditionally allowed for  
> identifier
> portablity and data rights. If you were to lose rights of access at  
> an OP
> (paypal dumps peter for violating service rule X) ... delegation  
> ensured
> that this 1 OP's suspension of Peter made no difference to Peter's  
> private
> life and Peter's relationship with RPs (becuase the protocols  
> automatically
> fell back on the next OP to which peter had delegated YOUR name).  
> Peter
> either could take such pre-cautions, or not - depending on his needs.
>
> What Im hearing in the LRPP story is not consistent with the  
> original openid
> user-centric story - targeting social networks (vs corporate  
> application
> outsourcing). The fear line seems to be implicitely denying the  
> legitimacy
> of user centric identity. In its marketing line, it seems to be  
> saying that:
> its far more important for consumers  to be free of fear, than be  
> free of a
> provider (when the relationship goes sour).
>
> Interesting changes going on in this movement!
>
>
>
>
>
>
>
> --
> View this message in context: http://www.nabble.com/user-centric-delegation-vs-portability%3A-LRDD-%3A-competing-threats%3A-the-consumer%27s-fear-hypothesis-tp26052720p26052720.html
> Sent from the OpenID - General mailing list archive at Nabble.com.
>
> _______________________________________________
> general mailing list
> general@...
> http://lists.openid.net/mailman/listinfo/openid-general

_______________________________________________
general mailing list
general@...
http://lists.openid.net/mailman/listinfo/openid-general

[Dirk Balfanz]

Hi Peter, 

thanks for your thoughtful response. 

As I see it, provider-independent identities are merely a means to an end. They shouldn't be the one-and-only litmus test applied to single sign-on solutions.

To me, what's important is that users can get quickly to a personalized experience across the web. That is - when I see a new web site, and it promises a useful service (which requires an account), I can immediately start using it. With just a few clicks, I can tell the service who I am, connect it to other services I use that it needs data from, etc.

I like the idea of provider-independent identities. It is one (although not the only) way to allow me to continue to use said service even when/if I leave my identity provider. However, that's but one of many considerations we need to make. If the only technical solution we can come up with is one that (1) features provider-independent identities and (2) increases hurdles to personalized web content (e.g., is too difficult to use by the majority of users), I have to admit I would start looking into whether relaxing requirement (1) could possibly help with problem (2) (not saying that currently OpenID falls into this category - just illustrating my priorities). 

It's true that I am a bit nervous, from a security point-of-view, about the delegation model used by OpenID today. As OpenID moves into the mainstream, I'm worried that a single "defacing" attack (i.e., one in which an attacker alters the content served from a certain server) can move the identity provider for a whole DNS domain to some machine under the control of an attacker. 

Finally (as John points out), delegation and provider-independent identities certainly aren't prevented by the proposed OpenID discovery mechanism. Sites like Blogger or Facebook, etc., could leave it up to their users to pick (and change) OpenID providers. If you have your own domain, you can pick (and change) your identity provider. But if you're one of 300,000 IBM employees, there are certain things you can't pick about your work account - you can't pick your email provider, you can't pick your calendaring software, and you can't presumably pick your identity provider - professionals at IBM who get paid to worry about this stuff will pick one for you that they are reasonably sure will not, say, put into jeopardy the 401k accounts of the combined IBM workforce (because, hypothetically speaking, IBM uses OpenID to log their employees into fidelity.com). 

We need a single sign-on solution for the Web that works both for Blogger/Facebook/consumer use case as well as the IBM use case.

Dirk.

On Sun, Oct 25, 2009 at 3:57 PM, Peter Williams <home_pw@...> wrote:

I found the writeup at http://hueniverse.com/2009/09/openid-and-lrdd/
convincing, technically. It moved the whole set of technical delegation
issues forward. It told a story. It was well written.

A. It reminded me of what Ping Identity once proposed for
dynamically-sharing SAML metadata between IDPs and (affiliations of) SP:
use a url-factory rule to deduce a URI from a domain name, get metadata from
said URL, and apply https/domain-cert controls to test for a saml entities
authority... to make assertions for that domain name. Optionally, sign the
metadata (much as one optionally signs XRDs). All Pretty obvious stuff
...but effective.

B. It reminded me of the leap forward of myopenid, when hosting outouurced
OPs via OPX (which uses DNS control principles to enable domain admins to
prove the delegated domain is authorizing the outsourcer to speak for it).

C. And, it reminded me of openid2, in that there are various flow fallbacks.
These allows communities to choose different flows (and thereby address
different players issue sets) when delegating and locating providers.

What I didnt like what the bias I heard throughout the writeup - concerning
the criteria I described in C.

Unlike the openid communities traditional mission (empower users, and give
them control over their data and names), there was a fear message at the
heart of it: focus on all that which COULD go wrong. And into that fear
rides the fearless knight on a white horse... the OP.

The fear said, users are easily duped and cannot in any case be trusted to
get it right - unlike the corporate CISO in whom we must trust. (Peter is a
CISO, by the way). Furthermore, we will bias the fallbacks so corporate CIOs
can control, before users control. If this was law, folks just coded their
bias in favor of the CIO and against the user/subscriber - through the
formulation of the legal presumptions.

Now, this bias may well be fine (if your audience is corporate buyers of
outsourced apps, leveraging openid protocols to get login sessions and
attributes). And, perhaps that is who the vendor is pitching its LRPP
technology to .

But, surely, the openid movement more generally needs to be focussed more
widely than only corporate sales -it also has consumer interests to
consider. If it fails here, it will risk falling into the pit that SAML fell
into - and fail to stay current with the larger currents of the web itself.
Historically (in the years before openid challenged SAML), every corporate
SAML link took a year, cost a million, was the bane of the CIO life, and
noone did two if they could avoid it.

Now, as oft associated with the Facebook brand, there are interplays between
the corporate control and consumer rights - particularly over data ownership
and identity control isues. And some mega-brands do better than others in
getting the balance right (and some actively hamper the user when
dis-associating from the brand, once things go sour). Some brands infamously
create explicit exit barriers (preventing you from exporting your contacts
to a file, say, or impose legal controls that limit just who you may (NOT)
choose to also work with).

When considering whether LRPP MAY be right for openid movement, we must
reflect that the openid movement is -or at least WAS - in the middle of
these issues, and took a position. It traditionally allowed for identifier
portablity and data rights. If you were to lose rights of access at an OP
(paypal dumps peter for violating service rule X) ... delegation ensured
that this 1 OP's suspension of Peter made no difference to Peter's private
life and Peter's relationship with RPs (becuase the protocols automatically
fell back on the next OP to which peter had delegated YOUR name). Peter
either could take such pre-cautions, or not - depending on his needs.

What Im hearing in the LRPP story is not consistent with the original openid
user-centric story - targeting social networks (vs corporate application
outsourcing). The fear line seems to be implicitely denying the legitimacy
of user centric identity. In its marketing line, it seems to be saying that:
its far more important for consumers  to be free of fear, than be free of a
provider (when the relationship goes sour).

Interesting changes going on in this movement!







--
View this message in context: http://www.nabble.com/user-centric-delegation-vs-portability%3A-LRDD-%3A-competing-threats%3A-the-consumer%27s-fear-hypothesis-tp26052720p26052720.html
Sent from the OpenID - General mailing list archive at Nabble.com.

_______________________________________________
general mailing list
general@...
http://lists.openid.net/mailman/listinfo/openid-general

_______________________________________________
general mailing list
general@...
http://lists.openid.net/mailman/listinfo/openid-general

[Manger, James H]

Some parts of this message have been removed. Learn more about Nabble's security policy.

Dirk,

 

I don’t think your IBM example is a very convincing argument for host-meta to take precedence over an actual OpenID URI. Listing an OP in host-meta may be a bit easier for an IBM IT admin than preventing links to OPs from other URIs — but the latter is quite feasible (rules in the page editing tool; filter in web server; validator on page changes; background script to look in the file system for this specific situation…). Even a non-technical corporate policy saying staff must not specify another OP goes some way to meeting the objective.

 

It is probably more convenient for host-meta to be able to provide a default OP, which can be overwritten for some special URIs. Most OpenID URIs on a host don’t specify an OP so they fallback to host-meta, but a few can use a different OP (for non-humans, for contractors, for testing, for migrating to a new OP implementation, for staff with a different hardware login token…).

 

 

James Manger
James.H.Manger@...
Identity and security team — Chief Technology Office — Telstra

 

From: openid-general-bounces@... [mailto:openid-general-bounces@...] On Behalf Of Dirk Balfanz
Sent: Tuesday, 27 October 2009 7:51 AM
To: Peter Williams
Cc: general@...
Subject: Re: [OpenID] user centric delegation vs portability: LRDD : competing threats: the consumer's fear hypothesis

 

…If you have your own domain, you can pick (and change) your identity provider. But if you're one of 300,000 IBM employees, there are certain things you can't pick about your work account - you can't pick your email provider, you can't pick your calendaring software, and you can't presumably pick your identity provider - professionals at IBM who get paid to worry about this stuff will pick one for you that they are reasonably sure will not, say, put into jeopardy the 401k accounts of the combined IBM workforce (because, hypothetically speaking, IBM uses OpenID to log their employees into fidelity.com). 

 

We need a single sign-on solution for the Web that works both for Blogger/Facebook/consumer use case as well as the IBM use case.

Dirk.

_______________________________________________
general mailing list
general@...
http://lists.openid.net/mailman/listinfo/openid-general

[John Bradley-9]

Host-meta doesn't provide the OP.

It provides a mapping from some identifier to a XRD for that identifier.

It is the target XRD for the user that specifies the OP.

Link link-headders can also provide the location of the XRD if you are using HTTP or another protocol that supports them.

host-meta is an additional way to map identifiers to XRD for things like email, or in cases where the site cant or just doesn't want to use link-headders.   

Link-headder is the replacement for the X-XRDS-Location custom header we were using in Yadis.

John B.

On 2009-10-26, at 8:28 PM, Manger, James H wrote:

Dirk,

 

I don’t think your IBM example is a very convincing argument for host-meta to take precedence over an actual OpenID URI. Listing an OP in host-meta may be a bit easier for an IBM IT admin than preventing links to OPs from other URIs — but the latter is quite feasible (rules in the page editing tool; filter in web server; validator on page changes; background script to look in the file system for this specific situation…). Even a non-technical corporate policy saying staff must not specify another OP goes some way to meeting the objective.

 

It is probably more convenient for host-meta to be able to provide a default OP, which can be overwritten for some special URIs. Most OpenID URIs on a host don’t specify an OP so they fallback to host-meta, but a few can use a different OP (for non-humans, for contractors, for testing, for migrating to a new OP implementation, for staff with a different hardware login token…).

 

 

James Manger 
James.H.Manger@... 
Identity and security team — Chief Technology Office — Telstra

 

From: openid-general-bounces@... [mailto:openid-general-bounces@...] On Behalf Of Dirk Balfanz
Sent: Tuesday, 27 October 2009 7:51 AM
To: Peter Williams
Cc: general@...
Subject: Re: [OpenID] user centric delegation vs portability: LRDD : competing threats: the consumer's fear hypothesis

 

…If you have your own domain, you can pick (and change) your identity provider. But if you're one of 300,000 IBM employees, there are certain things you can't pick about your work account - you can't pick your email provider, you can't pick your calendaring software, and you can't presumably pick your identity provider - professionals at IBM who get paid to worry about this stuff will pick one for you that they are reasonably sure will not, say, put into jeopardy the 401k accounts of the combined IBM workforce (because, hypothetically speaking, IBM uses OpenID to log their employees into fidelity.com). 

 

We need a single sign-on solution for the Web that works both for Blogger/Facebook/consumer use case as well as the IBM use case.

Dirk.

_______________________________________________
general mailing list
general@...
http://lists.openid.net/mailman/listinfo/openid-general

_______________________________________________
general mailing list
general@...
http://lists.openid.net/mailman/listinfo/openid-general

[Dirk Balfanz]

On Mon, Oct 26, 2009 at 4:28 PM, Manger, James H <James.H.Manger@...> wrote:

Dirk,

 

I don’t think your IBM example is a very convincing argument for host-meta to take precedence over an actual OpenID URI. Listing an OP in host-meta may be a bit easier for an IBM IT admin than preventing links to OPs from other URIs — but the latter is quite feasible (rules in the page editing tool; filter in web server; validator on page changes; background script to look in the file system for this specific situation…). Even a non-technical corporate policy saying staff must not specify another OP goes some way to meeting the objective.

I agree with all you're saying: having a policy might go "some way", background scripts looking for bad OPs in people's web pages can also catch problems, etc. Still, these would seem like work-arounds to a buggy spec to me, one in which an organization that otherwise can control what its users are doing down to very minute details (enforce anti-virus software on people's machines, for example) can suddenly not do this for a very security-sensitive issue (its users' identity provider). I would consider a spec in which users _had_ to rely on some admin to configure this for them also broken, for what it's worth. Like I said, we should try and address both use cases.

It is probably more convenient for host-meta to be able to provide a default OP, which can be overwritten for some special URIs.

You can do that under my proposal: You don't specify the OP in the host-meta. You use the Link-HTTP-header to point to the "default" XRD for most URIs (which in turn points to the "default" OP). You have some sort of process in which that Link-header can be set to point to a non-default XRD, which then points to a non-default OP. If a company/web site wants to do that, that's up to them.

Dirk.

 

Most OpenID URIs on a host don’t specify an OP so they fallback to host-meta, but a few can use a different OP (for non-humans, for contractors, for testing, for migrating to a new OP implementation, for staff with a different hardware login token…).

 

 

James Manger
James.H.Manger@...
Identity and security team — Chief Technology Office — Telstra

 

From: openid-general-bounces@... [mailto:openid-general-bounces@...] On Behalf Of Dirk Balfanz
Sent: Tuesday, 27 October 2009 7:51 AM
To: Peter Williams
Cc: general@...
Subject: Re: [OpenID] user centric delegation vs portability: LRDD : competing threats: the consumer's fear hypothesis

 

…If you have your own domain, you can pick (and change) your identity provider. But if you're one of 300,000 IBM employees, there are certain things you can't pick about your work account - you can't pick your email provider, you can't pick your calendaring software, and you can't presumably pick your identity provider - professionals at IBM who get paid to worry about this stuff will pick one for you that they are reasonably sure will not, say, put into jeopardy the 401k accounts of the combined IBM workforce (because, hypothetically speaking, IBM uses OpenID to log their employees into fidelity.com). 

 

We need a single sign-on solution for the Web that works both for Blogger/Facebook/consumer use case as well as the IBM use case.

Dirk.

_______________________________________________
general mailing list
general@...
http://lists.openid.net/mailman/listinfo/openid-general

_______________________________________________
general mailing list
general@...
http://lists.openid.net/mailman/listinfo/openid-general

[Santosh Rajan]

Hi John,

As you say the host-meta "provides a mapping from some identifier to a XRD for that identifier". This is true in the larger context.

However it is important to remember that it is not the "host-meta" itself that is doing the mapping. There is another application pointed to by the <URITemplate> that is actually doing the mapping.

So strictly speaking the host-meta "provides a mapping from an identifier to its resolver".

The host-meta is itself not doing the resolution, hence the host-meta need not be concerned with the resolution. Therefore it follows that the host-meta need not be concerned with the "scheme".

The whole "Scope" story is not required at all in this case.

In which case the <Subject> is required. The issue is then how you want to describe the Subject. "dns:example.com" should be good enough in this case.

On Tue, Oct 27, 2009 at 6:01 AM, John Bradley <ve7jtb@...> wrote:

Host-meta doesn't provide the OP.

It provides a mapping from some identifier to a XRD for that identifier.

It is the target XRD for the user that specifies the OP.

Link link-headders can also provide the location of the XRD if you are using HTTP or another protocol that supports them.

host-meta is an additional way to map identifiers to XRD for things like email, or in cases where the site cant or just doesn't want to use link-headders.   

Link-headder is the replacement for the X-XRDS-Location custom header we were using in Yadis.

John B.

On 2009-10-26, at 8:28 PM, Manger, James H wrote:

Dirk,

 

I don’t think your IBM example is a very convincing argument for host-meta to take precedence over an actual OpenID URI. Listing an OP in host-meta may be a bit easier for an IBM IT admin than preventing links to OPs from other URIs — but the latter is quite feasible (rules in the page editing tool; filter in web server; validator on page changes; background script to look in the file system for this specific situation…). Even a non-technical corporate policy saying staff must not specify another OP goes some way to meeting the objective.

 

It is probably more convenient for host-meta to be able to provide a default OP, which can be overwritten for some special URIs. Most OpenID URIs on a host don’t specify an OP so they fallback to host-meta, but a few can use a different OP (for non-humans, for contractors, for testing, for migrating to a new OP implementation, for staff with a different hardware login token…).

 

 

James Manger 
James.H.Manger@... 
Identity and security team — Chief Technology Office — Telstra

 

From: openid-general-bounces@... [mailto:openid-general-bounces@...] On Behalf Of Dirk Balfanz
Sent: Tuesday, 27 October 2009 7:51 AM
To: Peter Williams
Cc: general@...
Subject: Re: [OpenID] user centric delegation vs portability: LRDD : competing threats: the consumer's fear hypothesis

 

…If you have your own domain, you can pick (and change) your identity provider. But if you're one of 300,000 IBM employees, there are certain things you can't pick about your work account - you can't pick your email provider, you can't pick your calendaring software, and you can't presumably pick your identity provider - professionals at IBM who get paid to worry about this stuff will pick one for you that they are reasonably sure will not, say, put into jeopardy the 401k accounts of the combined IBM workforce (because, hypothetically speaking, IBM uses OpenID to log their employees into fidelity.com). 

 

We need a single sign-on solution for the Web that works both for Blogger/Facebook/consumer use case as well as the IBM use case.

Dirk.

_______________________________________________
general mailing list
general@...
http://lists.openid.net/mailman/listinfo/openid-general

_______________________________________________
general mailing list
general@...
http://lists.openid.net/mailman/listinfo/openid-general

--
http://hi.im/santosh

_______________________________________________
general mailing list
general@...
http://lists.openid.net/mailman/listinfo/openid-general

[Manger, James H]

Some parts of this message have been removed. Learn more about Nabble's security policy.

Dirk,

 

If a company gives total control of the contents of a set of URIs to staff members, then also wants to use those same URIs as controlled security-sensitive OpenID identifiers… then that is a disconnect that I doubt host-meta can or should try to paper over. Does any company do this?

If a company wants to control the OP it is trivial to offer official OpenID URIs for staff where staff have no control over their page (perhaps with the exception of a photo or blog link). Isn’t this how most major public OPs work today? It is well suited to entering “staff.example.com” at RPs, instead of a longer actual OpenID URI (say, staff.example.com/12345678).

 

>> It is probably more convenient for host-meta to be able to provide a default OP,
>> which can be overwritten for some special URIs.

> You can do that under my proposal: You don't specify the OP in the host-meta.

> You use the Link-HTTP-header to point to the "default" XRD for most URIs

> (which in turn points to the "default" OP). You have some sort of process in which

> that Link-header can be set to point to a non-default XRD,

> which then points to a non-default OP. If a company/web site wants to do that, that's up to them.

Sure, you can do it by ditching host-meta and doing something a bit more complicated. It will be painful if a site starts with host-meta for all; then wants 1 exception; so they have to ditch host-meta and switch to Link headers for everyone. In other words you have to be absolutely sure you will never want any exceptions if you choose the host-meta option (and it has priority).

 

The scenarios where a high-priority host-meta helps security seem rarer than the scenarios where a low-priority host-meta aids deployment, maintains user-centricity (and is more backwards compatible with existing OpenID)… but perhaps I still like URIs as identifier too much ;-)

 

James Manger

 

_______________________________________________
general mailing list
general@...
http://lists.openid.net/mailman/listinfo/openid-general

[John Bradley-9]

Don't think so.

Host-meta provides the template so that a resolver can find the XRD for the identifier.  

That XRD (likely a user XRD)  then provides links to related resources like the users OP.

Scope is required so that an entity that controls a DNS authority can say what protocols the host-meta XRD contains valid mappings for.

If there is a subject of a host-meta XRD it needs to relate to the DNS names or names in the SSL cert used to sign it.

I think there are two issues.

1 Authority  (relates to signing keys)

2 what URI schemes and ports the XRD contains mappings for.

I think the latest drafts of WebFinger has them somewhat conflated.

My personal preference would be to use <Subject> for trust and some other elements to describe scope.

However mine is just one opinion.

No I don't think <Subject> needs to be required in XRD.

Regards

John B.

On 2009-10-27, at 1:10 AM, Santosh Rajan wrote:

Hi John,

As you say the host-meta "provides a mapping from some identifier to a XRD for that identifier". This is true in the larger context.

However it is important to remember that it is not the "host-meta" itself that is doing the mapping. There is another application pointed to by the <URITemplate> that is actually doing the mapping.

So strictly speaking the host-meta "provides a mapping from an identifier to its resolver".

The host-meta is itself not doing the resolution, hence the host-meta need not be concerned with the resolution. Therefore it follows that the host-meta need not be concerned with the "scheme".

The whole "Scope" story is not required at all in this case.

In which case the <Subject> is required. The issue is then how you want to describe the Subject. "dns:example.com" should be good enough in this case.

On Tue, Oct 27, 2009 at 6:01 AM, John Bradley <ve7jtb@...> wrote:

Host-meta doesn't provide the OP.

It provides a mapping from some identifier to a XRD for that identifier.

It is the target XRD for the user that specifies the OP.

Link link-headders can also provide the location of the XRD if you are using HTTP or another protocol that supports them.

host-meta is an additional way to map identifiers to XRD for things like email, or in cases where the site cant or just doesn't want to use link-headders.   

Link-headder is the replacement for the X-XRDS-Location custom header we were using in Yadis.

John B.

On 2009-10-26, at 8:28 PM, Manger, James H wrote:

Dirk,

 

I don’t think your IBM example is a very convincing argument for host-meta to take precedence over an actual OpenID URI. Listing an OP in host-meta may be a bit easier for an IBM IT admin than preventing links to OPs from other URIs — but the latter is quite feasible (rules in the page editing tool; filter in web server; validator on page changes; background script to look in the file system for this specific situation…). Even a non-technical corporate policy saying staff must not specify another OP goes some way to meeting the objective.

 

It is probably more convenient for host-meta to be able to provide a default OP, which can be overwritten for some special URIs. Most OpenID URIs on a host don’t specify an OP so they fallback to host-meta, but a few can use a different OP (for non-humans, for contractors, for testing, for migrating to a new OP implementation, for staff with a different hardware login token…).

 

 

James Manger 
James.H.Manger@... 
Identity and security team — Chief Technology Office — Telstra

 

From: openid-general-bounces@... [mailto:openid-general-bounces@...] On Behalf Of Dirk Balfanz
Sent: Tuesday, 27 October 2009 7:51 AM
To: Peter Williams
Cc: general@...
Subject: Re: [OpenID] user centric delegation vs portability: LRDD : competing threats: the consumer's fear hypothesis

 

…If you have your own domain, you can pick (and change) your identity provider. But if you're one of 300,000 IBM employees, there are certain things you can't pick about your work account - you can't pick your email provider, you can't pick your calendaring software, and you can't presumably pick your identity provider - professionals at IBM who get paid to worry about this stuff will pick one for you that they are reasonably sure will not, say, put into jeopardy the 401k accounts of the combined IBM workforce (because, hypothetically speaking, IBM uses OpenID to log their employees into fidelity.com). 

 

We need a single sign-on solution for the Web that works both for Blogger/Facebook/consumer use case as well as the IBM use case.

Dirk.

_______________________________________________
general mailing list
general@...
http://lists.openid.net/mailman/listinfo/openid-general

_______________________________________________
general mailing list
general@...
http://lists.openid.net/mailman/listinfo/openid-general

--
http://hi.im/santosh

_______________________________________________
general mailing list
general@...
http://lists.openid.net/mailman/listinfo/openid-general

[John Bradley-9]

James,

If a site say IBM uses site-meta to map URL's to XRD there is nothing to stop them from giving an individual edit access to the XRD so they can map there services to wherever they like.

It makes it harder to have an exception for hosting a single XRD someplace else.

They can use link headers if they want to allow users to host there XRD at arbitrary locations.

However they would still need to sign the XRD if the subject is there URI and they are not using host-meta to delegate.

host-meta is about controlling where the XRD are and not about controlling the OP.

They are related but separate issues.

John B.

On 2009-10-27, at 4:09 AM, Manger, James H wrote:

Dirk,

 

If a company gives total control of the contents of a set of URIs to staff members, then also wants to use those same URIs as controlled security-sensitive OpenID identifiers… then that is a disconnect that I doubt host-meta can or should try to paper over. Does any company do this?

If a company wants to control the OP it is trivial to offer official OpenID URIs for staff where staff have no control over their page (perhaps with the exception of a photo or blog link). Isn’t this how most major public OPs work today? It is well suited to entering “staff.example.com” at RPs, instead of a longer actual OpenID URI (say, staff.example.com/12345678).

 

>> It is probably more convenient for host-meta to be able to provide a default OP,
>> which can be overwritten for some special URIs.

> You can do that under my proposal: You don't specify the OP in the host-meta.

> You use the Link-HTTP-header to point to the "default" XRD for most URIs

> (which in turn points to the "default" OP). You have some sort of process in which

> that Link-header can be set to point to a non-default XRD,

> which then points to a non-default OP. If a company/web site wants to do that, that's up to them.

Sure, you can do it by ditching host-meta and doing something a bit more complicated. It will be painful if a site starts with host-meta for all; then wants 1 exception; so they have to ditch host-meta and switch to Link headers for everyone. In other words you have to be absolutely sure you will never want any exceptions if you choose the host-meta option (and it has priority).

 

The scenarios where a high-priority host-meta helps security seem rarer than the scenarios where a low-priority host-meta aids deployment, maintains user-centricity (and is more backwards compatible with existing OpenID)… but perhaps I still like URIs as identifier too much ;-)

 

James Manger

 

_______________________________________________
general mailing list
general@...
http://lists.openid.net/mailman/listinfo/openid-general

_______________________________________________
general mailing list
general@...
http://lists.openid.net/mailman/listinfo/openid-general

[Peter Williams]

Some parts of this message have been removed. Learn more about Nabble's security policy.

One thing we might recognize as a community that there are now three sub-communities messaging on openid (and 1.5 years ago there was only one – and it had a typical evangelist-phase tone).

 

Certain potential adoptees (as an industry) almost bought into the message of 1.5 years ago (the paradigm shift of user centric content, delegation operated by parties other than OPs, user portability, correlation of ids with content left at a hundred RPs, …) as a reason to pick openid SSO over SAML SSO, etc). That message is now “almost” being repudiated. Perhaps folks remember when there was the notion that ancien security was out, and nuveau “identity” was in? Anyone who thought in the memes of “security” was not going to get “identity” in the web2.0 era (despite I&A being one of the staples of any “corporate” security program). Within a year, things reverted somewhat to normal (focusing on the CISO’s needs and the standard governance points).

 

1.       There is the google message – making openid into a solid piece of enterprise middleware that can facilitate app outsourcing by enterprises to cloud providers – and thence link enterprises to consumers/subscribers. Instead of ws-federation redirect URI or ws-trust, do openid redirects. Let host-meta el al do for app domains what sts metadata would otherwise do when orchestrating the proxying of w-security/ws-trust communications through a value-adding SOA cloud provider.

 

2.       There is the relic of the social network message – making openid into a trust fabric for the public space (accessing even .gov under that community’s paranoid privacy practices). These web2.5 memes address long term social issues around privacy policies and the fundamental TTP trust relationship megaportals have with consumers. (This whole issue set recaptures the moment of VeriSign birth to my mind, in a earlier era.) Today, this is perhaps most obviously represented by LiveID – the public portal of half a billion users (where I’m trying to distinguish the LiveID pitch from the Azure group’s pitch, just within the Microsoft’s own storyline)

 

3.       There is the continuing message from several sources – derived from the SUN/Concordia message of about 2 years ago –that  openid is forever a lightweight SSO (in comparison to SAML2). It is as yet  technically “unfinished” and cannot be legitimately applied yet to anything of any sensitivity or criticality -- until “elementary” technical and governance issues have been addressed (see above). Half the time this comes across as the old SAML vendor community attempting to invoke market delaying tactics (bad! on them), and half the time it seems to be about the SAML technical folk re-invigorating their community for a multi-protocol world that can share the stage with openid and ws-fed [and perhaps even foaf+ssl] (good! on them).

 

Ive never been before to a internet identity workshop, which I hope to do next week. I’m hoping it will somehow address the changing of the message on user centric’ness in identity systems. I don’t believe it’s something than can simply be spun away.

 

 

 

From: Dirk Balfanz [mailto:balfanz@...]
Sent: Monday, October 26, 2009 1:51 PM
To: Peter Williams
Cc: general@...
Subject: Re: [OpenID] user centric delegation vs portability: LRDD : competing threats: the consumer's fear hypothesis

 

Hi Peter, 

 

thanks for your thoughtful response. 

 

As I see it, provider-independent identities are merely a means to an end. They shouldn't be the one-and-only litmus test applied to single sign-on solutions.

 

To me, what's important is that users can get quickly to a personalized experience across the web. That is - when I see a new web site, and it promises a useful service (which requires an account), I can immediately start using it. With just a few clicks, I can tell the service who I am, connect it to other services I use that it needs data from, etc.

 

I like the idea of provider-independent identities. It is one (although not the only) way to allow me to continue to use said service even when/if I leave my identity provider. However, that's but one of many considerations we need to make. If the only technical solution we can come up with is one that (1) features provider-independent identities and (2) increases hurdles to personalized web content (e.g., is too difficult to use by the majority of users), I have to admit I would start looking into whether relaxing requirement (1) could possibly help with problem (2) (not saying that currently OpenID falls into this category - just illustrating my priorities). 

 

It's true that I am a bit nervous, from a security point-of-view, about the delegation model used by OpenID today. As OpenID moves into the mainstream, I'm worried that a single "defacing" attack (i.e., one in which an attacker alters the content served from a certain server) can move the identity provider for a whole DNS domain to some machine under the control of an attacker. 

 

Finally (as John points out), delegation and provider-independent identities certainly aren't prevented by the proposed OpenID discovery mechanism. Sites like Blogger or Facebook, etc., could leave it up to their users to pick (and change) OpenID providers. If you have your own domain, you can pick (and change) your identity provider. But if you're one of 300,000 IBM employees, there are certain things you can't pick about your work account - you can't pick your email provider, you can't pick your calendaring software, and you can't presumably pick your identity provider - professionals at IBM who get paid to worry about this stuff will pick one for you that they are reasonably sure will not, say, put into jeopardy the 401k accounts of the combined IBM workforce (because, hypothetically speaking, IBM uses OpenID to log their employees into fidelity.com). 

 

We need a single sign-on solution for the Web that works both for Blogger/Facebook/consumer use case as well as the IBM use case.

Dirk.

 

On Sun, Oct 25, 2009 at 3:57 PM, Peter Williams <home_pw@...> wrote:

I found the writeup at http://hueniverse.com/2009/09/openid-and-lrdd/
convincing, technically. It moved the whole set of technical delegation
issues forward. It told a story. It was well written.

A. It reminded me of what Ping Identity once proposed for
dynamically-sharing SAML metadata between IDPs and (affiliations of) SP:
use a url-factory rule to deduce a URI from a domain name, get metadata from
said URL, and apply https/domain-cert controls to test for a saml entities
authority... to make assertions for that domain name. Optionally, sign the
metadata (much as one optionally signs XRDs). All Pretty obvious stuff
...but effective.

B. It reminded me of the leap forward of myopenid, when hosting outouurced
OPs via OPX (which uses DNS control principles to enable domain admins to
prove the delegated domain is authorizing the outsourcer to speak for it).

C. And, it reminded me of openid2, in that there are various flow fallbacks.
These allows communities to choose different flows (and thereby address
different players issue sets) when delegating and locating providers.

What I didnt like what the bias I heard throughout the writeup - concerning
the criteria I described in C.

Unlike the openid communities traditional mission (empower users, and give
them control over their data and names), there was a fear message at the
heart of it: focus on all that which COULD go wrong. And into that fear
rides the fearless knight on a white horse... the OP.

The fear said, users are easily duped and cannot in any case be trusted to
get it right - unlike the corporate CISO in whom we must trust. (Peter is a
CISO, by the way). Furthermore, we will bias the fallbacks so corporate CIOs
can control, before users control. If this was law, folks just coded their
bias in favor of the CIO and against the user/subscriber - through the
formulation of the legal presumptions.

Now, this bias may well be fine (if your audience is corporate buyers of
outsourced apps, leveraging openid protocols to get login sessions and
attributes). And, perhaps that is who the vendor is pitching its LRPP
technology to .

But, surely, the openid movement more generally needs to be focussed more
widely than only corporate sales -it also has consumer interests to
consider. If it fails here, it will risk falling into the pit that SAML fell
into - and fail to stay current with the larger currents of the web itself.
Historically (in the years before openid challenged SAML), every corporate
SAML link took a year, cost a million, was the bane of the CIO life, and
noone did two if they could avoid it.

Now, as oft associated with the Facebook brand, there are interplays between
the corporate control and consumer rights - particularly over data ownership
and identity control isues. And some mega-brands do better than others in
getting the balance right (and some actively hamper the user when
dis-associating from the brand, once things go sour). Some brands infamously
create explicit exit barriers (preventing you from exporting your contacts
to a file, say, or impose legal controls that limit just who you may (NOT)
choose to also work with).

When considering whether LRPP MAY be right for openid movement, we must
reflect that the openid movement is -or at least WAS - in the middle of
these issues, and took a position. It traditionally allowed for identifier
portablity and data rights. If you were to lose rights of access at an OP
(paypal dumps peter for violating service rule X) ... delegation ensured
that this 1 OP's suspension of Peter made no difference to Peter's private
life and Peter's relationship with RPs (becuase the protocols automatically
fell back on the next OP to which peter had delegated YOUR name). Peter
either could take such pre-cautions, or not - depending on his needs.

What Im hearing in the LRPP story is not consistent with the original openid
user-centric story - targeting social networks (vs corporate application
outsourcing). The fear line seems to be implicitely denying the legitimacy
of user centric identity. In its marketing line, it seems to be saying that:
its far more important for consumers  to be free of fear, than be free of a
provider (when the relationship goes sour).

Interesting changes going on in this movement!







--
View this message in context: http://www.nabble.com/user-centric-delegation-vs-portability%3A-LRDD-%3A-competing-threats%3A-the-consumer%27s-fear-hypothesis-tp26052720p26052720.html
Sent from the OpenID - General mailing list archive at Nabble.com.

_______________________________________________
general mailing list
general@...
http://lists.openid.net/mailman/listinfo/openid-general

 

_______________________________________________
general mailing list
general@...
http://lists.openid.net/mailman/listinfo/openid-general

[Manger, James H]

Some parts of this message have been removed. Learn more about Nabble's security policy.

John,

 

> Host-meta doesn't provide the OP.

> It provides a mapping from some identifier to a XRD for that identifier.

> It is the target XRD for the user that specifies the OP.

 

Thanks for reminding me of the extra layer of indirection.

That does mean a solution where host-meta takes precedence still has some flexibility to handle, say, a different OP for just a few special OpenID URIs on a site.

 

 

Host-meta now uses the XRD syntax. It no longer just looks like a mapping from identifiers to the metadata (XRD) for each identifier. It now looks like common metadata (XRD) for a host of identifiers, optionally with a reference to more identifier-specific metadata (XRD).

 

If host-meta can say: the ‘describedby’ link for all URIs at this host is xyz; why shouldn’t it say the ‘openid2.provider’ link for all URIs at this host is abc? The semantics seem to work, as long as RPs are looking for this relation in host-meta.

 

A ‘describedby’ link in an XRD looks like an app-layer version of an HTTP redirect: you can have 0, 1, or more of them. [Perhaps an “@import url(…)” statement in a cascading stylesheet is a better analogy, as it also has issues of merging data from various sources.]

I guess a higher layer, like OpenID, might choose to mandate that “there MUST be exactly 1 level of indirection” (ie host-meta SHALL specify a ‘describedby’ link, but no ‘openid*’ links; whereas an OpenID identifier’s XRD SHALL NOT include a ‘describedby’ link).

 

James Manger
James.H.Manger@...
Identity and security team — Chief Technology Office — Telstra

_______________________________________________
general mailing list
general@...
http://lists.openid.net/mailman/listinfo/openid-general

[John Bradley-9]

I don't think openID will look in the host-meta for the OP.  

I suppose that it could but that would defiantly not be user centric behaviour.

Users don't enter a host-meta identifier.   It is used as one of the ways to discover the XRD for an identifier.

It is not a XRD for the identifier itself.

In the case of example.com if I want to find the XRD for https://example.com (say it is used as a OP identifier for directed identity) and example.com doesn't want to use link headers for some reason.

The resolver first retrieves host-mata from the well known location.

It retrieves it via https or verifies the signature of the XRD.

(Yes Santosh if the XRD had dns:example.com as the subject that would work to verify it)

The resolver then determines if the XRD's scope includes https.

If it is in scope the resolver uses the matching template for the scheme + host + port with https://example.com as the input and produces the new URI where the XRD for https://example.com can be retrieved from.

It could be http://bar.com/xrd/example.com or anything else for that matter.

It is the Links in that XRD that control who the OP is.

There are lurking questions about if a XRD retrieved over http can be authoritative for schemes other than the one it was retrieved via.

My contention is that the subject (it may not be called that) of the XRD is the subject of the SSL certificate that is signing it.

The XRD should be self standing.  This is important if you want it to be able to map identifiers that don't have there own transport protocol that can return a document.   I would class email addresses as that.  Yes you could modify SMTP but you don't want to.

I prefer to think of host-meta as being part of the X.509 trust chain that can delegate trust to down stream XRD rather than something that is rooted directly in the URI authority hierarchy.

The discussion is ongoing.  My opinion may well not be the majority one at the end of the day.

John B.

On 2009-10-27, at 9:49 PM, Manger, James H wrote:

John,

 

> Host-meta doesn't provide the OP.

> It provides a mapping from some identifier to a XRD for that identifier.

> It is the target XRD for the user that specifies the OP.

 

Thanks for reminding me of the extra layer of indirection.

That does mean a solution where host-meta takes precedence still has some flexibility to handle, say, a different OP for just a few special OpenID URIs on a site.

 

 

Host-meta now uses the XRD syntax. It no longer just looks like a mapping from identifiers to the metadata (XRD) for each identifier. It now looks like common metadata (XRD) for a host of identifiers, optionally with a reference to more identifier-specific metadata (XRD).

 

If host-meta can say: the ‘describedby’ link for all URIs at this host is xyz; why shouldn’t it say the ‘openid2.provider’ link for all URIs at this host is abc? The semantics seem to work, as long as RPs are looking for this relation in host-meta.

 

A ‘describedby’ link in an XRD looks like an app-layer version of an HTTP redirect: you can have 0, 1, or more of them. [Perhaps an “@import url(…)” statement in a cascading stylesheet is a better analogy, as it also has issues of merging data from various sources.]

I guess a higher layer, like OpenID, might choose to mandate that “there MUST be exactly 1 level of indirection” (ie host-meta SHALL specify a ‘describedby’ link, but no ‘openid*’ links; whereas an OpenID identifier’s XRD SHALL NOT include a ‘describedby’ link).

 

James Manger 
James.H.Manger@... 
Identity and security team — Chief Technology Office — Telstra

_______________________________________________
general mailing list
general@...
http://lists.openid.net/mailman/listinfo/openid-general

_______________________________________________
general mailing list
general@...
http://lists.openid.net/mailman/listinfo/openid-general