RE: [OpenID] OpenID Extension to handle Emails Addresses?

[Hallam-Baker, Phillip]

Maybe because the DNS naming system is the Internet for all practical purposes.
 
Think about the telephone system. What parts of the system today have remained 
the same for a century? Pretty much everything has changed, the telephones, the 
switches, the wires, even the assignment of the numbers themselves.
 
But the basic interface of 'dial number X to talk to Y' has remained constant.
 
The DNS is the equivalent infrastructure for the Internet. Everything else will 
change over time. We are currently changing the packet protocol from IPv4 to 
IPv6 and many parts of the Web are not on the Internet at all, the are URLs 
embedded in print media, in CD Rom and such.
 
The implementation will change, you might even see new TLDs replace .com or the 
rise of www.microsoft or whatever. But every such change must and will be 
incremental. 
 
 
I am not quite sure to interpret the last paragraph. The term 'walled garden' 
is a loaded one. It is used to refer to the carrier model where the carrier 
decides where the consumer is allowed to go. I don't think that is what end 
users want.
 
But what they might well want is a model where they get to define the fences 
themselves. So they can fence off their financial browser from the anonymizing 
Web browser they use to view folk dancing Web sites and the like.
 
Its really a matter of who gets to decide where the fence goes...



From: Peter Williams [mailto:[EMAIL PROTECTED]
Sent: Thu 10/30/2008 3:09 PM
To: Martin Atkins; Hallam-Baker, Phillip
Cc: specs@openid.net; OpenID List
Subject: RE: [OpenID] OpenID Extension to handle Emails Addresses?



Verisign wants validation of id related to dns (and dnssec).

Wonder why?

As long as an op can verify the dns assuraces and communciate them to the rp as 
a certificate (re)minted by itself, there is a compromise to be had here.

Perhaps the op adds the domain to its own walled garden dns server, does its 
own dnssec, and lets its consumers bind over an mpls vpn and virual routing 
domain to its dns service.. That would be consistent with the openid model: as 
the rp app chooses the dns access point, not the op.

-Original Message-
From: Martin Atkins <[EMAIL PROTECTED]>
Sent: Thursday, October 30, 2008 2:51 PM
To: Hallam-Baker, Phillip <[EMAIL PROTECTED]>
Cc: specs@openid.net ; OpenID List <[EMAIL PROTECTED]>
Subject: Re: [OpenID] OpenID Extension to handle Emails Addresses?


Hallam-Baker, Phillip wrote:
>
> Well we already have a specification for that, it is the core
> architecture of the Internet: DNS. We use the DNS SRV record for service
> discovery. It is what it is designed for. It provides for fault
> tolerance, load balancing, fall over just like an email MX record.
>

Thanks for another voice in favor of DNS. I was beginning to feel like
the only one on this side of the fence. :)

> The simplest discovery mechanism then is:
>
> _openid.example.com   SRV 1 100 80 openid.example.com
>

I did consider SRV, but the "return value" from OpenID discovery is not
a hostname, it's a structure like this:

  * Endpoint URL
  * "Final" claimed identifier (after following redirects)
  * OP-local identifier (or "delegate" in 1.1 terminology)
  * OpenID version (either 1.1 or 2.0, currently)

Some of these we can infer. For example, in my DNS-based proposal I just
assumed that all email-based identifiers would use OpenID 2.0, because a
provider's going to have to change their implementation anyway so they
might as well upgrade to 2.0 while they're at it if they don't support
it already.

I went with a TXT record with a custom serialization, despite it being
technically incorrect, both so that the information required for the
above structure could be represented and also so that it can be deployed
on DNS providers that only allow A, CNAME, MX and TXT records to be
configured. The latter is important for the delegation case, as the main
  audience for delegation is people with vanity domains.

>
> OK so now lets think about market building a bit. Lets try to embrace
> and extend the competition. In my view the value of OpenID is not so
> much the protocol as the idea of an interoperable identifier. So lets
> try to capture the SAML and WS-* worlds as well.
>
> We can do this with a policy declaration:
>
> _openid.example.com TXT "v=openid openid saml"
> _openid.example.com   SRV 1 100 80 openid1.example.com
> _openid.example.com   SRV 1 100 80 openid2.example.com
> _saml.example.com   SRV 1 100 80 saml1.example.com
> _saml.example.com   SRV 1 100 80 saml2.example.com
>

And I infer from this that you're not adverse to the idea of encoding
custom formats in TXT records, so hopefully you'll appreciate my approach.

However, if you've got an alternative proposal that's more "DNS-pure"
I

RE: [OpenID] OpenID Extension to handle Emails Addresses?

[Hallam-Baker, Phillip]

The Internet has an identifier for users - it is their email address. Trying to 
tech users to use anything else is pointless.

As far as I am concerned, we have a hierarchy of usability interests here:

Users: 
They come first, their needs are paramount and trump all others.

Authentication consumers: 
They come next, make admin as easy as possible, but not if it is going to 
hurt users. We can expect an auth consumer to have a properly configured DNS 
server or fix their server if broken. 

Identity providers:
This is a serious business. I don't consider it necessary to make barriers 
to entry any lower than they currently are for administering a mail server. 


At the moment the URL centric spec seems to have this hierarchy stood on its 
head. In order to make matters easy for authentication providers the user is 
expected to futz with URLs. I have a dozen blogs, I have never considered them 
to be part of my core identity. They are attributes, not my name. 


So we have an identifier, [EMAIL PROTECTED], how do we resolve it?

Well we already have a specification for that, it is the core architecture of 
the Internet: DNS. We use the DNS SRV record for service discovery. It is what 
it is designed for. It provides for fault tolerance, load balancing, fall over 
just like an email MX record.

The simplest discovery mechanism then is:

_openid.example.com   SRV 1 100 80 openid.example.com


or for fault tolerance:

_openid.example.com   SRV 1 100 80 openid1.example.com
_openid.example.com   SRV 1 100 80 openid2.example.com

or we can redirect to a third party:

_openid.example.com   PTR pip.verisignlabs.com

Any competent network admin can configure SRV records using any of the 
mainstream DNS servers that have come out in the past 8 years. Windows 2000 
uses SRV as a core service.

There is no need for users to know this is going on, the only point where the 
SRC is required is that the identity server has to advertise the service and 
the authentication consumer app has to be able to read it. 



OK so now lets think about market building a bit. Lets try to embrace and 
extend the competition. In my view the value of OpenID is not so much the 
protocol as the idea of an interoperable identifier. So lets try to capture the 
SAML and WS-* worlds as well.

We can do this with a policy declaration:

_openid.example.com TXT "v=openid openid saml"
_openid.example.com   SRV 1 100 80 openid1.example.com
_openid.example.com   SRV 1 100 80 openid2.example.com
_saml.example.com   SRV 1 100 80 saml1.example.com
_saml.example.com   SRV 1 100 80 saml2.example.com


We don't need to just stop at establishing identity either. We can use this as 
a means of deploying the type of exotic authentication protocols that Stefan 
Brands and myself have developed which allow for anonymous authorization 
without authentication.


Someone is going to do federated auth this way sooner or later. It is the 
obvious way to do it that is consistent with the Internet architecture. 

The only real arguable point in what I wrote is that I do not have solid data 
on how users will react. It is my hypothesis that they will find an email 
address easier than a URL. If folk want to argue that point lets test it out. 

The main obstacle to change here would be the effect on the legacy base. We 
would need to get the identity providers to upgrade (easy) and the web sites to 
upgrade (harder) and there would have to be some sort of change over period 
that we would need to think through.


-Original Message-
From: [EMAIL PROTECTED] on behalf of David Fuelling
Sent: Thu 10/30/2008 12:20 PM
To: Martin Atkins
Cc: specs@openid.net; OpenID List
Subject: Re: [OpenID] OpenID Extension to handle Emails Addresses?
 
On Thu, Oct 30, 2008 at 4:01 PM, Martin Atkins <[EMAIL PROTECTED]>wrote:

> David Fuelling wrote:
>
>>
>> I would even entertain the notion of the OpenID extension doing DNS lookup
>> first, then EAUT, though I need to think more on the topic.  Alternatively,
>> maybe we make DNS optional.
>>
>>
> At this point I'll throw in my more recent post about why DNS must be
> supported and must be the primary mode, with others as fallback:
>
> http://www.apparently.me.uk/18285.html
>
>
Very interesting points in your blog post!!  It has me wondering the
following questions:


   1. The arguments about using DNS could apply to OpenID in general.
   However, OpenID doesn't do anything with DNS.  Why is this?  What were the
   compelling reasons to not use DNS with OpenID?  Is there an FAQ page
   somewhere about that?  I have only vague recollections on the topic.
   2. Do some of the larger email providers have an opinion on the mechanism
   used for "Discovery" in the email case?  For instance, would
   Google/Yahoo/etc prefer that DNS be consulted first, or that some HTTP-based
   discovery be consulted first?  Do they even care?



> However, I wouldn't necessarily object to putting the *EAUT* information
>  in the DNS rather 

RE: OpenID Email Discovery

[Hallam-Baker, Phillip]

On the contrary, you require the SSL certificate to match the domain of the 
identifier being authenticated and the problem is solved.

Alternatively you use a scheme such as SAML to perform the authentication which 
would provide more flexibility than a transport layer security model.

One reason I strongly prefer the email identifier approach is precisely because 
it maps so much better to PKI. 

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of Trevor Johns
> Sent: Friday, January 04, 2008 6:08 AM
> To: Artur Bergman
> Cc: 'OpenID specs list'
> Subject: Re: OpenID Email Discovery
> 
> On Jan 4, 2008, at 1:59 AM, Artur Bergman wrote:
> 
> > Fair or not, I am tired of hearing how un-secure DNS, when 
> everything 
> > we do is based on it, and it being the worlds largest working 
> > distributed database.
> 
> There's a difference between working and secure. For example, 
> email works great but it's far from secure.
> 
> > There is SSL connecting to the provider that is being refereed from 
> > the srv/txt field. Which is no different than what you are 
> referenced 
> > to from an A or CNAME or MX
> 
> Which is why I said it depends on what is used as the claimed 
> identifier. If the user's email address is used as the 
> claimed identifier and I am able to change the user's record from:
> 
>   example.com   TXT   ‘OpenID * 10 https://*.example.com/’
> 
> to:
> 
>   example.com   TXT   ‘OpenID * 10 https://*.myevilsite.com/’
> 
> then all the SSL in the world won't help.
> 
> If the email address _isn't_ the claimed identifier, then the 
> end user has to validate that their OP-local identifier 
> (which they don't know) is displayed correctly by the service 
> provider. This is worse than an SSL failure, there isn't even 
> a dialog asking them to click OK!
> 
> > Not that it matters anyway, since people just click OK.
> 
> 
> If a service provider detects an SSL failure, there's no 
> person there to press okay. Their server will just summarily 
> deny the authentication request.
> 
> The "click OK" problem is only between client-server communication.  
> This is server-server communication.
> 
> --
> Trevor Johns
> http://tjohns.net
> 
> ___
> 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 Email Discovery

[Hallam-Baker, Phillip]

You can use domain validated SSL certificates or DNSSEC here. Either is 
sufficient. 

There is no technology gap here.  

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of Artur Bergman
> Sent: Friday, January 04, 2008 6:14 AM
> To: Trevor Johns
> Cc: 'OpenID specs list'
> Subject: Re: OpenID Email Discovery
> 
> 
> On Jan 4, 2008, at 12:07 PM, Trevor Johns wrote:
> 
> > On Jan 4, 2008, at 1:59 AM, Artur Bergman wrote:
> >
> >> Fair or not, I am tired of hearing how un-secure DNS, when 
> everything 
> >> we do is based on it, and it being the worlds largest working 
> >> distributed database.
> >
> > There's a difference between working and secure. For example, email 
> > works great but it's far from secure.
> >
> 
> Whatever, this discussion is old and bores me. You can always go out  
> and use DNSSEC.
> 
> >> There is SSL connecting to the provider that is being refereed  
> >> from the srv/txt field. Which is no different than what you are  
> >> referenced to from an A or CNAME or MX
> >
> > Which is why I said it depends on what is used as the claimed  
> > identifier. If the user's email address is used as the claimed  
> > identifier and I am able to change the user's record from:
> >
> > example.com   TXT   ‘OpenID * 10 https://*.example.com/’
> >
> > to:
> >
> > example.com   TXT   ‘OpenID * 10 https://*.myevilsite.com/’
> >
> > then all the SSL in the world won't help.
> >
> > If the email address _isn't_ the claimed identifier, then the end  
> > user has to validate that their OP-local identifier (which they  
> > don't know) is displayed correctly by the service provider. 
> This is  
> > worse than an SSL failure, there isn't even a dialog asking 
> them to  
> > click OK!
> >
> >> Not that it matters anyway, since people just click OK.
> >
> >
> > If a service provider detects an SSL failure, there's no person  
> > there to press okay. Their server will just summarily deny the  
> > authentication request.
> >
> > The "click OK" problem is only between client-server 
> communication.  
> > This is server-server communication.
> 
> Isn't this just a lookup of email address -> openid/url that is then  
> handled as a normal openid login?
> 
> Artur
> 
> ___
> 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 Email Discovery

[Hallam-Baker, Phillip]

 for supporting leveraged authentication. If we separate 
the OpenId protocol from the discovery framework the authentication protocol 
negotiation mechanism could then become the architecurally precise means of 
deploying OpenId and the ad-hoc workarround discovery mechanisms may be 
regarded as fixes to support legacy infrastructure, build the deployed base etc.
 
 
If we use the TXT plus SRV record approach we are able to support 100% of 
legacy authentication protocols and infrastructure in a manner that is 
compatible with 98% of the deployed DNS infrastructure or better and consistent 
with IETF standards. The only minor deviation here is using TXT to express the 
new policy records.
 
Being able to support any authentication protocol in this manner means that the 
proposal is potentially one that can bring together all the different efforts 
in the space. It adds value for SAML, Liberty, CardSpace and Higgins supporters.
 
 


From: Peter Davis [mailto:[EMAIL PROTECTED]
Sent: Fri 04/01/2008 8:56 AM
To: Hallam-Baker, Phillip
Cc: Eran Hammer-Lahav; OpenID specs list
Subject: Re: OpenID Email Discovery



On Jan 3, 2008, at 6:03 PM, Hallam-Baker, Phillip wrote:

> NAPTR is an ietf proposed standard but there is no deployed base.

well, there certainly are deployed bases where i sit, since we have 
DNS zones in operation with well over 40M entries... most of which 
are NAPTR RR's, and many, many users of these services.

The reason i made the suggestion, however, is that the proposed 
solution (of using TXT RRs) showed examples of regx like functions 
for resolvers to post-process... which is precisely what NAPTR RRs 
were intended to provided (among other things) and that use of TXT 
RRs are being discouraged.  the SRV RR does not provide any 
facilities for regx-like answers.

=peterd




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

Re: OpenID Email Discovery

[Hallam-Baker, Phillip]

NAPTR is an ietf proposed standard but there is no deployed base. SRV has been 
supported in windows since 2000 and bind since before then.

XRI is a specification, not an OASIS recommendation. Until the IPR commitments 
necessary to allow that change are made there is no standard.


Sent from my GoodLink Wireless Handheld (www.good.com)

 -Original Message-
From:   Peter Davis [mailto:[EMAIL PROTECTED]
Sent:   Thursday, January 03, 2008 02:07 PM Pacific Standard Time
To: Hallam-Baker, Phillip
Cc: Eran Hammer-Lahav; OpenID specs list
Subject:Re: OpenID Email Discovery

actually, NAPTR RR's would be a better fit, as the unique-part of an  
openID may be in the local-path part of a URI, not the hostname... of  
course, if a users openID changes, so too might their underlying DNS  
name, and then DNS won't help you at all there.  XRI is better  
situated to solve that use case.

=peterd

On Jan 3, 2008, at 4:48 PM, Hallam-Baker, Phillip wrote:

> This is the function of the existing DNS SRV record.
>
> _openid.example.com  SRV 1 1 1 1 openid1.example.com
>
> The Internet has an architecture already. Use it, don't try to  
> reinvent it.
>
> From: [EMAIL PROTECTED] on behalf of Eran Hammer-Lahav
> Sent: Thu 03/01/2008 4:01 PM
> To: 'OpenID specs list'
> Subject: OpenID Email Discovery
>
> (The full story is posted at http://www.hueniverse.com/hueniverse/ 
> 2008/01/addressing-open.html but this contains the technical parts  
> of the post).
>
>
> This proposal adds Email Discovery allowing users to use their  
> email address as an OpenID.
>
>
> ...
>
>
> We need to map between the email to the OpenID identifier and this  
> is where DNS comes in. DNS already has a system for resolving email  
> addresses into an actual server - email resolution using an MX  
> record. Why not add a new record type for OpenID. Basically another  
> way to perform OpenID discovery that is all about making it user- 
> friendly.
>
>
> All that is needed is a URL the site performing discovery can  
> append the email to and treat it as an OpenID identifier. This can  
> be done using a OpenID TXT record: 'OpenID [username rule]  
> [priority] [URL]' where [username rule] is a wildcard expression  
> used to match the username part of the email (everything up to the  
> '@'), [priority] is the MX-like priority value, and [URL] is the  
> URL used to generate the OpenID identifier. The URL uses '*' to  
> indicate where the username is inserted, and '**' to indicate where  
> the full, URL-encoded, email address is inserted (both optional).  
> For example:
>
>
> example.com   TXT   'OpenID * 10 http://*.example.com/'
>
> example.com   TXT   'OpenID joe 10 http://example.org/openid?**'
>
>
> Which reads: for any email address '@example.com' other than 'joe'  
> use 'http://username.example.com/' as the OpenID identifier. For  
> email address '[EMAIL PROTECTED]' use 'http://example.org/openid?joe% 
> 40example.com' as the OpenID identifier. Rules are processed first  
> based on the username rule match (in order of match closeness) and  
> then on priority which is used in the same manner as MX records  
> priority.
>
>
> ...
>
>
> There are many ways to implement identity delegation, but in the  
> context of email identifiers and simplifying the user experience,  
> the idea is to move the delegation mapping to the OpenID provider.  
> When users sign-up for a new OpenID, they will be given the option,  
> perhaps as a premium paid service, to make the OpenID provider map  
> incoming identity checks for the user email address with their  
> local OpenID identifier. So instead of the users telling the site  
> about their local identity (using delegation), the OpenID provider  
> will perform the mapping.
>
>
> In the above example, '[EMAIL PROTECTED]' has his OpenID managed by  
> 'example.org'. When signing up for an OpenID at 'example.org', Joe  
> asked it to accept identity requests for '[EMAIL PROTECTED]' or at  
> least provide delegation discovery. When Joe tries to log into an  
> OpenID-enabled site using '[EMAIL PROTECTED]', the site convert the  
> email address to the URL 'http://example.org/openid?joe% 
> 40example.com' and use it like a regular OpenID identifier.  
> 'example.org' will reply with the needed discovery information to  
> get Joe authenticated using the OpenID protocol. By using the '**'  
> symbol, the full email address is sent over to the OpenID provider  
> which can perform mapping of identities other than its own l

RE: OpenID Email Discovery

[Hallam-Baker, Phillip]

This is the function of the existing DNS SRV record.
 
_openid.example.com  SRV 1 1 1 1 openid1.example.com
 
The Internet has an architecture already. Use it, don't try to reinvent it.



From: [EMAIL PROTECTED] on behalf of Eran Hammer-Lahav
Sent: Thu 03/01/2008 4:01 PM
To: 'OpenID specs list'
Subject: OpenID Email Discovery



(The full story is posted at 
http://www.hueniverse.com/hueniverse/2008/01/addressing-open.html but this 
contains the technical parts of the post).

 

This proposal adds Email Discovery allowing users to use their email address as 
an OpenID.

 

...

 

We need to map between the email to the OpenID identifier and this is where DNS 
comes in. DNS already has a system for resolving email addresses into an actual 
server - email resolution using an MX record. Why not add a new record type for 
OpenID. Basically another way to perform OpenID discovery that is all about 
making it user-friendly.

 

All that is needed is a URL the site performing discovery can append the email 
to and treat it as an OpenID identifier. This can be done using a OpenID TXT 
record: 'OpenID [username rule] [priority] [URL]' where [username rule] is a 
wildcard expression used to match the username part of the email (everything up 
to the '@'), [priority] is the MX-like priority value, and [URL] is the URL 
used to generate the OpenID identifier. The URL uses '*' to indicate where the 
username is inserted, and '**' to indicate where the full, URL-encoded, email 
address is inserted (both optional). For example:

 

example.com   TXT   'OpenID * 10 http://*.example.com/'

example.com   TXT   'OpenID joe 10 http://example.org/openid?**'

 

Which reads: for any email address '@example.com' other than 'joe' use 
'http://username.example.com/' as the OpenID identifier. For email address 
'[EMAIL PROTECTED]' use 'http://example.org/openid?joe%40example.com' as the 
OpenID identifier. Rules are processed first based on the username rule match 
(in order of match closeness) and then on priority which is used in the same 
manner as MX records priority.

 

...

 

There are many ways to implement identity delegation, but in the context of 
email identifiers and simplifying the user experience, the idea is to move the 
delegation mapping to the OpenID provider. When users sign-up for a new OpenID, 
they will be given the option, perhaps as a premium paid service, to make the 
OpenID provider map incoming identity checks for the user email address with 
their local OpenID identifier. So instead of the users telling the site about 
their local identity (using delegation), the OpenID provider will perform the 
mapping.

 

In the above example, '[EMAIL PROTECTED]' has his OpenID managed by 
'example.org'. When signing up for an OpenID at 'example.org', Joe asked it to 
accept identity requests for '[EMAIL PROTECTED]' or at least provide delegation 
discovery. When Joe tries to log into an OpenID-enabled site using '[EMAIL 
PROTECTED]', the site convert the email address to the URL 
'http://example.org/openid?joe%40example.com' and use it like a regular OpenID 
identifier. 'example.org' will reply with the needed discovery information to 
get Joe authenticated using the OpenID protocol. By using the '**' symbol, the 
full email address is sent over to the OpenID provider which can perform 
mapping of identities other than its own local ones.

 

This can be viewed as hosted delegated identity where the OpenID provider also 
provides hosting of the OpenID delegation information for the user. It doesn't 
require any new standards except for implementation and support by OpenID 
providers.

 

---

 

Would love to get some feedback.

 

Thanks,

 

EHL

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

RE: [OpenID] Wiki page: Attempting to document the "Email Address asOpenId" debate.

[Hallam-Baker, Phillip]

The mailto: scheme was not our finest hour.

When it was designed none of us really understood fully that we were conflating 
the method and the identifier. In particular we only defined methods for HTTP, 
not for other protocols.

In that case of mailto: the identifier apparently conflates the method 
(ASYNCHRONOUS-POST) and the resource identifier ([EMAIL PROTECTED]).  If we had 
been thinking a bit further we might have defined an mechanism RFC822:[EMAIL 
PROTECTED] and a set of methods (asynchronous-POST, SYNCHRONOUS-CONNECT etc.).


We can always define our own URI scheme: OPENID:[EMAIL PROTECTED]

This can then map to multiple resolution protocols at the option of the 
registry providing the service as described through configuration data 
expressed through the DNS.


In this way OPENID becomes the lynchpin of the next generation Internet 
identity system embracing and extending SMTP, JABBER and Blogging while at the 
same time preserving current human factors.

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of Robert Yates
> Sent: Wednesday, February 14, 2007 11:54 AM
> To: Stephane Bortzmeyer
> Cc: Claus Färber; specs@openid.net; [EMAIL PROTECTED]
> Subject: Re: [OpenID] Wiki page: Attempting to document the 
> "Email Address asOpenId" debate.
> 
> On 2/14/07, Stephane Bortzmeyer <[EMAIL PROTECTED]> wrote:
> >
> > A real-world example is NAI (Network Access Identifiers) in 
> RFC 4282.
> >
> > Mine is [EMAIL PROTECTED] Certainly not an email address.
> 
> Is a URI scheme defined for RFC 4282?, I took a quick look 
> and couldn't find one.
> 
> As Phillip keeps pointing out [1] [2] there is an important 
> distinction between what the user is expected to type and the 
> canonical representation used by the machines. IMO, this wiki page
> *should* be about mailto: URI's as openids and not other 
> machine representations that happen to use the same user format.
> 
> Rob
> 
> [1] http://openid.net/pipermail/general/2007-February/001705.html
> [2] http://openid.net/pipermail/specs/2006-November/000811.html
> ___
> 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] Wiki page: Attempting to document the "Email Addressas OpenId"debate.

[Hallam-Baker, Phillip]

> Hallam-Baker, Phillip wrote:
> > 
> > Over time everyone will own their own DNS domain
>  > and it will form the hub of their personal  > 
> communications system. All communication modes  > will map 
> onto the single unified communication identifier.
> > 
> 
> I don't necessarily disagree with many of your arguments, but 
> I wonder why — if everyone owns their own DNS domain — we 
> even need the user@ portion anymore? Largely that was 
> included because in the early days — and even today, for many 
> people — their addresses were [EMAIL PROTECTED]

I agree. Example.com should be default be interpreted as a first class 
identifier.


> My primary personal email address (not the one I use for 
> mailing lists) is pretty redundant since the part before the 
> @ is the same as the part after the @ once the parent domain 
> has been excluded. Leaving off the user@ portion doesn't make 
> the address any less "mine".

The main issue here is who owns the naming registry. Under what circumstances 
does a name change control? The ICANN infrastructure is cumbersome but 
essential. Trying to replicate the DNS and ignoring the needs that led to the 
creation of ICANN is doomed. Trying to establish a proprietary registry is the 
sort of dotcom nonsense everyone apart from O'Riely and his Web 2.0 types have 
grown out of by now.


> Calling a Jabber ID an email address is a bit misleading. 

OK call it an RFC 822 format address then.

> It's entirely possible for the email address [EMAIL PROTECTED] 
> and the JID [EMAIL PROTECTED] to be owned/controlled by 
> different people. It is not safe to assume that the two are 
> the same person without evidence of that. What makes a string 
> like "[EMAIL PROTECTED]" an email address is the fact that you 
> can address email to it. The fact that the two addressing 
> schemes use similar syntax doesn't help you much.

On the contrary there is a very high degree of probability that they are the 
same. 
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

RE: [OpenID] Wiki page: Attempting to document the "Email Address asOpenId" debate.

[Hallam-Baker, Phillip]

The semantics of an identifier arise from its usage.

It is of course entirely possible that someone might configure their system in 
such a way that the Kerberos principal [EMAIL PROTECTED] was different from the 
person with email address [EMAIL PROTECTED] was different from the person with 
Jabber address [EMAIL PROTECTED]

But it is rather unlikely that the party who created this situation would be 
unaware of the potential for confusion. 


If there is an OpenID identifier [EMAIL PROTECTED] there may or may not be an 
SMTP server willing to accept mail for that address. If there is such a server 
the domain name owner should be expected to understand the consequences of the 
identifiers mapping to different principals and take whatever steps are felt 
necessary to ensure this.



> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of David Fuelling
> Sent: Sunday, February 11, 2007 9:42 PM
> To: 'Claus Färber'
> Cc: specs@openid.net; [EMAIL PROTECTED]
> Subject: RE: [OpenID] Wiki page: Attempting to document the 
> "Email Address asOpenId" debate.
> 
> > -Original Message-
> > From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] 
> > On Behalf Of Claus Färber
> >>
> >> http://openid.net/wiki/index.php?title=Debating_Emails_as_OpenIds
> > 
> > I'd prefer to call them [EMAIL PROTECTED] OpenIDs. The concept of 
> using this 
> > format is not only used for email but also for other types of 
> > identifiers such as RADIUS zones or Kerberos realms.
> > 
> > For example, [EMAIL PROTECTED] could be a RADIUS login, a Kerberos 
> > principal and a Yadis ID/OpenID but not an email address.
> > 
> 
> HmmmI'm not sure about this one.  I intentionally rooted 
> my definition of "Email Address" in RFC2822, which is where 
> it should be rooted (if we're going to call them 'email 
> addresses').  Seems like anything in the form '[EMAIL PROTECTED]' 
> would also have an identical root (RFC2822).
> 
> Is that not the case for Kerberos realms and RADIUS zones?  
> In other words, are these *not* also email addresses? 
> 
> david
> 
> ___
> 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: Wiki page: Attempting to document the "Email Address as OpenId"debate.

[Hallam-Baker, Phillip]

I think that it is very important to remember that there are two separate 
identifier issues here:

1) What the user is expected to type.
2) The cannonical representation used by the machines. 

In the pre-Mosaic Web browsers the URI simply did not appear in the primary 
chrome. Open URI was a drop down menu option with a secondary dialogue. The 
idea was that addresses were something that remained under the covers and just 
like the SGML like angle brackets were never seen (HTML only became a fully 
compliant SGML markup later on).


The page is making tenuous distinctions between URLs and URIs that are 
unfortunately 100% bogus. The whole URN/URL/URI nonsense was a huge mistake as 
Tim Berners-Lee himself has lamented on numerous occasions, including last 
month when I discussed the issue with him. The URN/URL thing was never his 
idea, it was forced on him early on in the development of the Web when he was 
looking for buy in. URNs are URLs and URLs are URNs, If I take an ISBN it is 
nominally a URN but enter int into Amazon.com and click buy now and it just 
became a URL.

Empirically email addresses are an important form of net identifier. If they 
don't fit into a taxonomic scheme that someone is peddling the answer is to 
jettison the scheme. Just use the nomenclature that Tim suggested in the first 
place. 

The only useful distinction to make here is by the registry. There is an 
important difference between an email address and an ISBN. The first is relies 
on the DNS system for its semantics, the second relies on the ISBN registry for 
its semantics.

The only way to make a DNS name more permanent is to attach it to a 
registration scheme that makes it more permanent. So combine a DNS name and 
time and you have a permanent identifier albeit one that can only be resolved 
directly while the name continues to be owned by the same party.


The only case where the choice of identifier makes a real difference is when it 
is used as a contact address. An authenticated blog URL is a form of contact 
address. An email address is another which offers greater interaction.

An email address is a contact address, it is not necessarily the only contact 
address. If someone is offering blog hosting services to people they can also 
offer email should they choose. This is not likely to be the blogger's only 
email address unless and until something remarkable has been done in the spam 
control field.


An 'email' address is simply the conventional conjunction of a username portion 
and a DNS name portion. It need not be used only for email, nor is it. It is 
routine for people to use RFC822 addresses for Jabber and other instant 
messaging applications.

Over time everyone will own their own DNS domain and it will form the hub of 
their personal communications system. All communication modes will map onto the 
single unified communication identifier.

By far the most likely identifier to be chosen for this purpose is the RFC822 
email identifier. It is embedded in the system at this point.


> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of David Fuelling
> Sent: Saturday, February 10, 2007 3:54 PM
> To: [EMAIL PROTECTED]
> Cc: specs@openid.net
> Subject: Wiki page: Attempting to document the "Email Address 
> as OpenId"debate.
> 
> Hi List,
> 
> In light of my recent extension proposal to map Email 
> Addresses to OpenId URLs, I have setup a wiki page on 
> openid.net that attempts to capture all the pro/cons/issues 
> that have been shared in the debate over whether this is a 
> good idea or not.
> 
> http://openid.net/wiki/index.php?title=Debating_Emails_as_OpenIds
> 
> I have tried as best I can to present a "non-partisan" wiki 
> page that simply details the pros/cons of each argument.  
> Basically, the point is to document all sides of the debate, 
> and *not* to endorse one side or the other.
> 
> That said, I'm sure some of my bias is present in the initial 
> wording, so please feel free to suggest changes to my 
> wording, or make them yourself. 
> 
> In addition, please add additional arguments and rebuttals as 
> you see fit.
> The page is not nearly exhaustive (I plan to add some 
> "arguments in favor" + rebuttals tomorrow when I have time).
> 
> Thanks!
> 
> David
> 
> ___
> 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: Proposal: An anti-phishing compromise

[Hallam-Baker, Phillip]

I think that it is an excellent idea since it allows us to have it both ways. 
We can continue to offer backwards compatibility with legacy infrastructure 
without compromising the strength of the strongest schemes.
 

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of Josh Hoyt
> Sent: Thursday, February 01, 2007 4:42 PM
> To: OpenID specs list
> Subject: Proposal: An anti-phishing compromise
> 
> Hello,
> 
> I've written up a proposal for an addition to the OpenID 
> Authentication 2.0 specification that addresses the phishing problem.
> I've had some off-list discussion of it, and I think it may 
> strike the right balance. Please provide feedback.
> 
> Josh
> 
> Background
> ==
> 
> We have had a lot of good discussion about how phishing 
> relates to OpenID. There seems to be consensus that the 
> OpenID Authentication spec should address these issues, but 
> not consensus on how that should happen.
> 
> The ways that OpenID can potentially make phishing worse:
> 
>  * Redirects to your provider are a fundamental part of the 
> flow of OpenID, so being redirected to a phishing site is easy to miss
> 
>  * Every relying party (necessarily) needs to know who the 
> provider is in order to verify the authentication response. 
> This means that the site knows what UI it needs to use to 
> phish (and even worse, it can just proxy the user to the provider)
> 
> I think these two issues cover what makes phishing 
> potentially a greater threat when using OpenID.
> 
> Although these problems are significant, if a user can 
> authenticate to their OpenID provider through an 
> "non-phishable" mechanism, OpenID can make the phishing 
> problem *less* of a threat, because there are fewer places 
> that will need to ask for credentials.
> 
> Other relevant issues:
> 
>   * There is no universally deployed solution to the phishing problem
> 
>   * There is not even a universally *accepted* solution to 
> the phishing problem
> 
>   * Any technology that prevents phishing will require 
> user-agent support or else will fundamentally change the flow 
> of OpenID (prevent relying-party-initiated sign-in)
> 
>   * OpenID is intended to be deployed without requiring 
> specific technologies to be present in the user-agent
> 
>   * Any general anti-phishing technology can be applied to OpenID
> 
> Proposed Change
> ===
> 
> Add a single, required, boolean field to the authentication 
> response that specifies whether or not the method the OP used 
> to authenticate the user is phishable. The specification will 
> have to provide guidelines on what properties an 
> authentication mechanism needs to have in order to be 
> "non-phishable." The field is just meant to indicate that the 
> authentication mechanism that was used is not a standard 
> "secret entered into a Web form."
> 
> Analysis
> 
> 
> This proposal is a simplification of the Assertion Quality 
> Extension [1] (AQE), and is essentially the same as what Ben 
> Laurie proposed earlier [2]. It does not attempt to replace 
> the AQE or require it for authentication in general.
> 
> Benefits
> 
> 
> The proposal is trivial implement, it acknowledges that 
> phishing is a problem, and forces implementers think about 
> it. If more assurances are required, then the AQE, 
> whitelists, and other mechanisms still need to be employed. 
> This field just sets a minimum bar.
> 
> I think that this is the right information to require, 
> because it addresses this one thing that makes OpenID 
> potentially worse for security, but it does not mandate 
> specific technologies.
> 
> It pushes the liability for phishing relying parties to 
> OpenID providers, who are the ones who should be responsible 
> for taking measures to prevent phishing. IANAL, so I don't 
> know if this has any real teeth, but it does make it clear to 
> people who are implementing OpenID providers that it is 
> intended to be their responsibility to deal with the phishing issues.
> 
> Drawbacks
> -
> 
> It may be tricky to define what is meant by "non-phishable."
> 
> There is no way for a Relying Party to *ensure* that the 
> OpenID provider indeed uses "non-phishable" authentication.
> 
> If libraries are used, the library user may not read the 
> relevant parts of the specification about phishing, and so 
> may remain ignorant of the phishing issues.
> 
> Why this should be in the core spec
> ---
> 
> I believe that this one piece of information would be 
> required more often than not, given the phishing 
> implications. The prominence of being in the core 
> specification makes it harder to ignore the phishing problem.
> 
> References
> ==
> 
> 1. 
> http://openid.net/specs/openid-assertion-quality-extension-1_0-03.html
> 2. http://openid.net/pipermail/general/2007-January/001340.html
> ___
> specs mailing list
> specs@openi

RE: OpenID Auth 2.0 security considerations

[Hallam-Baker, Phillip]

I get really worried whenever I see such statements. They tend to be the sign 
of a long drawn out specification effort rather than a short one.

If you want to change the Internet you have a lot of gatekeepers to convince. 
Deciding that you don't have time to do that is usually a mistake. 

The key is to understand which parties are really gatekeepers and which are 
not. Two gatekeepers that must be convinced here are the security cabal and the 
open source community. 

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of Johannes Ernst
> Sent: Tuesday, January 23, 2007 3:57 PM
> To: Recordon, David
> Cc: specs@openid.net
> Subject: Re: OpenID Auth 2.0 security considerations
> 
> Given where we are in time, I would suggest to make the 
> smallest amount of changes possible to the document, i.e. 
> leave everything as is, just add this one link.
> 
> 
> On Jan 23, 2007, at 11:59, Recordon, David wrote:
> 
> > I don't see a problem with that.
> >
> > Would you propose the majority of the security 
> considerations section 
> > in the current draft be moved to the wiki?  What would be 
> the balance 
> > between spec and wiki page?
> >
> > --David
> >
> > -Original Message-
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On 
> > Behalf Of Johannes Ernst
> > Sent: Monday, January 22, 2007 12:15 PM
> > To: specs@openid.net
> > Subject: OpenID Auth 2.0 security considerations
> >
> > What about a non-normative link from the spec to a place on 
> the wiki 
> > where we can collect security considerations for it, and 
> update those 
> > in real-time as discussions such as the phishing one progress.
> >
> >
> >
> > ___
> > 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] Announcing OpenID Authentication 2.0 - Implementor'sDraft 11

[Hallam-Baker, Phillip]

SSL achieves the original security goals set for it.

SSL does not achieve every security goal, that is not a failure. Certainly 
there are no grounds for the claim PKI has failed when it has succeeded in its 
original limited goals.

I agree that the original goals were too narrow. That is an argument I made ten 
years ago.

This is partly about correcting that original mistake.

> -Original Message-
> From: Ka-Ping Yee [mailto:[EMAIL PROTECTED] 
> Sent: Monday, January 22, 2007 3:05 PM
> To: Hallam-Baker, Phillip
> Cc: James A. Donald; Ben Laurie; specs@openid.net; 
> openid-general; heraldry-dev@incubator.apache.org
> Subject: Re: [OpenID] Announcing OpenID Authentication 2.0 - 
> Implementor'sDraft 11
> 
> On Mon, 22 Jan 2007, Hallam-Baker, Phillip wrote:
> > On the contrary, PKI is the basis of the security 
> infrastructure that 
> > so far has provided the greatest defense against Internet 
> crime - SSL.
> >
> > Judged by any rational set of standards SSL has been the most 
> > successful security protocol of all time. The costs of the PKI 
> > infrastructure are negligible compared to the value of the 
> commerce it 
> > supports.
> 
> In practice SSL is primarily used to establish an encrypted 
> channel between endpoints, not to establish reliable 
> reciprocal identification.
> Given that almost no users pay any attention to certificates, 
> what reason do we have to believe that SSL succeeds because 
> of PKI, rather than in spite of it?
> 
> By what rational set of standards do you evaluate PKI -- how 
> frequently it is used, or how much fraud it actually prevents?
> 
> 
> -- ?!ng
> 
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

RE: [OpenID] Announcing OpenID Authentication 2.0 - Implementor'sDraft 11

[Hallam-Baker, Phillip]

On the contrary, PKI is the basis of the security infrastructure that so far 
has provided the greatest defense against Internet crime - SSL.

Judged by any rational set of standards SSL has been the most successful 
security protocol of all time. The costs of the PKI infrastructure are 
negligible compared to the value of the commerce it supports.


There are uses of S/MIME that do provide effective security controls for the 
community that applies them. But any CA that continues to advocate per-user 
certs in place of domain level authentication has failled to understand their 
real business interests.

> -Original Message-
> From: James A. Donald [mailto:[EMAIL PROTECTED] 
> Sent: Monday, January 22, 2007 1:42 PM
> To: Ben Laurie
> Cc: Hallam-Baker, Phillip; specs@openid.net; openid-general; 
> heraldry-dev@incubator.apache.org
> Subject: Re: [OpenID] Announcing OpenID Authentication 2.0 - 
> Implementor'sDraft 11
> 
> Hallam-Baker, Phillip
>  > > > If you change the browser you might as well really  > 
> > > change the browser and use a strong authentication  > > > 
> mechanism based on PKI
> 
> Ben Laurie
>  > > I'm sure you meant to say "based on asymmetric  > > 
> cryptography".
> 
> Hallam-Baker, Phillip
>  > No, any time you have a trusted key you have an  > infrastructure.
> 
> No you do not, nor is PKI useful in solving phishing.
> 
> PKI is a solution that has been tried and has failed.
> It has become an obstacle, as commercial interests actively 
> block alternatives that do not involve a small number of 
> centralized authorities with a special privilege that enables 
> them to intrude between client and server and charge the server.
> 
> 
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

RE: [OpenID] Announcing OpenID Authentication 2.0 - Implementor'sDraft 11

[Hallam-Baker, Phillip]

> From: Ben Laurie [mailto:[EMAIL PROTECTED] 

> > The only way that I can see that you are going to 
> circumvent an attempt using existing browser capabilities is 
> to introduce a malicious login page is through use of some 
> form of shared secret such as a picture of a cuddly animal 
> chosen by the user or Secure Letterhead.
> 
> How is this kind of shared secret a defence against a MitM?

Good question to address to those vendors selling such schemes.

There are controls that can be put in place to control attempts to capture the 
shared secret but these rely on a lot of active defense infrastructure that it 
is dangerous to assume could be deployed by low end IdPs. The bigger problem is 
getting users to insist on the display of their secret before entering their 
details. Witness the recent rash of phishing attacks against these schemes.


> > Letterhead requires a browser upgrade so it breaks the 
> 'existing capabilities' constraint.
> >
> > If you change the browser you might as well really change 
> the browser 
> > and use a strong authentication mechanism based on PKI
> 
> I'm sure you meant to say "based on asymmetric cryptography".

No, any time you have a trusted key you have an infrastructure.

Some infrastructures have much higher costs than others. Support for offline 
verification as the Kohnfelder architecture attempts is very expensive. Key 
centric architectures are much lighter weight. 

The reason I state PKI is not to say 'it must be X.509', its because PKIX got 
the way it did largely because people underspecified and underarchitected in 
the beginning and then a bunch of folk resisted necessary features rather than 
working out early on how to accommodate them. The result being a series of 
extensions on extensions and no overall coherence.

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

RE: [OpenID] Announcing OpenID Authentication 2.0 - Implementor'sDraft 11

[Hallam-Baker, Phillip]

 
> [mailto:[EMAIL PROTECTED] On Behalf Of Ben Laurie

> More importantly, I think I have a solution that will make 
> both of us happy, but I now have to go and ride my motorbike 
> fast, so I'll detail it later.

Now there is an exit line to tempt the Gods.


The only way that I can see that you are going to circumvent an attempt using 
existing browser capabilities is to introduce a malicious login page is through 
use of some form of shared secret such as a picture of a cuddly animal chosen 
by the user or Secure Letterhead.

Letterhead requires a browser upgrade so it breaks the 'existing capabilities' 
constraint. 

If you change the browser you might as well really change the browser and use a 
strong authentication mechanism based on PKI


I think we need to take another look at the 'change the browser' case and make 
sure that we can take full advantage if the browser is changed.
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

RE: Federated Authorization

[Hallam-Baker, Phillip]

The SAML specification is designed to target this precise set of requirements, 
it has widespread support amongst vendors who support enterprise class products.
 
If you want to have a third party accreditation of a statement such as 'Dr 
Cripps is a licensed medical practitioner' it is going to be exceptionally hard 
to persuade them to use any format other than either an X.509v3 attribute 
assertion or a SAML assertion. From my point of view X.509v3 attribute 
assertions are not very interesting as they bind the statement to an X.509v3 
key certificate and thus a public key and not the entity that is certified. 
This ties the whole system to X.509/PKIX as the authentication infrastructure.
 
You can certainly use SAML in conjunction with an OpenID authentication 
mechanism. As far as SAML is concerned all that it cares about is that it has 
an identifier to bind to.
 
I don't think that the OpenID group wants to do the level of architecture that 
would be required to address authorization either. To make a statement of the 
type you suggest requires detailed consideration of the legal and liability 
issues. SAML is designed to address these, that is why it has the Audience 
constraint and is one motivation for the constraint mechanism.
 
 
The pieces SAML lacks are standard mechanisms for discovery and standard 
identifiers. These would not be at all hard to define. Define the identifier to 
be a URI and instantiate an SRV based discovery mechanism.
 




From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of 
McGovern, James F (HTSC, IT)
Sent: Thursday, January 18, 2007 11:52 AM
To: specs@openid.net
Subject: Federated Authorization



I would love to see folks hear that also blog not only continue to 
discuss federated identity but also consider of the course of several 
additional postings also talk about the need for federated authorization. 
Consider an example where a Doctor in a hospital is having an electronic 
interaction with a healthcare insurance provider. The hospital should be the 
identity provider while the entity that licensed the Doctor for given sets of 
practices should be responsible for certain forms of authorization.

If we only talk about identity without authorization, the conversation 
will result in lots of great software where folks who create them won't make 
any money since consumer-centric interactions have volume without corresponding 
revenue. 




*
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] Opened IPR Policy Draft

[Hallam-Baker, Phillip]

The problem is not the people who contribute, it's the ones who never join the 
group or agree to any license because they never intend to make or sell 
anything.

Align with the standards bodies, that way we have the option of going to a 
standards body later.

I have been through the pain here... The concern I have is that we don't end up 
in the situation that caused one of my standards groups I was trying to form to 
implode during formation.

I want to standardize the legal part of the process. Mozilla is not a good 
model, there are ideological commitments there which are not widely appreciated 
and in certain quarters distinctly unappreciated.

 

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of David Nicol
> Sent: Tuesday, December 12, 2006 2:02 PM
> To: James A. Donald
> Cc: specs@openid.net; Martin Atkins; Gavin Baumanis; 
> [EMAIL PROTECTED]
> Subject: Re: [OpenID] Opened IPR Policy Draft
> 
> On 12/12/06, James A. Donald <[EMAIL PROTECTED]> wrote:
> > Changes and enhancements to the openID standard are 
> patentable.  When 
> > the standard was originally proposed, it was far from clear that it 
> > would be widely adopted, so it is unlikely that anyone 
> patented it in 
> > time, so the original standard is safe from IP.
> 
> What a headache.  Let's get whoever makes the best reference 
> implementation to release it MPL.  Mozilla PL has viral 
> patent grant language in it while explicitly allowing MPLd 
> code to be included in "Larger Projects."  (not sure about 
> the viral nature of the patent grant language; if we want a 
> viral patent grant we might have to create the OIDPL or something)
> 
> 
> 
> --
> perl -le'1while(1x++$_)=~/^(11+)\1+$/||print'
> ___
> 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] Opened IPR Policy Draft

[Hallam-Baker, Phillip]

Not a good model. Before the Web the number of patent trolls was much smaller 
and they were less vicious.

HTTP was designed at CERN which explicitly released all the IPR into the public 
domain. 

Even then there have been many issues and many cases with disgraceful outcomes. 
Plenty of my own work was stolen.

> -Original Message-
> From: Chris Messina [mailto:[EMAIL PROTECTED] 
> Sent: Monday, December 11, 2006 9:51 PM
> To: Hallam-Baker, Phillip
> Cc: David Nicol; Gavin Baumanis; Martin Atkins; 
> specs@openid.net; [EMAIL PROTECTED]
> Subject: Re: [OpenID] Opened IPR Policy Draft
> 
> Excuse my ignorance, but what's the IPR that governs 
> protocols like IMAP and HTTP?
> 
> Would we be able to take a similar tack with OpenID?
> 
> Chris
> 
> On 12/11/06, Hallam-Baker, Phillip <[EMAIL PROTECTED]> wrote:
> > Don't worry about the patent trolls there is only one way 
> to stop them and that is not to have any money worth stealing.
> >
> > There are probably snots already reading the list archive 
> so they can claim to have invented stuff. Someone claimed to 
> have invented one IETF standard five years after the group started.
> >
> > Fortunately the USPTO is slightly more selective these days 
> and the publication period gives us a chance to try a new 
> tactic: lets file a writ for perjury on the alleged 
> inventors. Probably won't go anywhere but given the history 
> its worth a try.
> >
> >
> > > -Original Message-
> > > From: [EMAIL PROTECTED]
> > > [mailto:[EMAIL PROTECTED] On Behalf Of David Nicol
> > > Sent: Monday, December 11, 2006 3:04 PM
> > > To: Gavin Baumanis
> > > Cc: specs@openid.net; Martin Atkins; [EMAIL PROTECTED]; James A. 
> > > Donald
> > > Subject: Re: [OpenID] Opened IPR Policy Draft
> > >
> > > but the openID standard is more than a year old already.
> > >
> > > On 12/10/06, Gavin Baumanis <[EMAIL PROTECTED]> wrote:
> > > > > So the technology is first proposed and described on this
> > > list, on
> > > > > 2006 December 7, 2006.  It is incorporated into the 
> standard and 
> > > > > comes to be widely used around about, say, 2007 
> August.  On 2007 
> > > > > December 5, 2007, the patent troll has a friendly individual 
> > > > > inventor file an p! atent application claiming to have
> > > invented the
> > > > > technology on 2007, december 6.
> > > ___
> > > specs mailing list
> > > specs@openid.net
> > > http://openid.net/mailman/listinfo/specs
> > >
> > >
> > ___
> > general mailing list
> > [EMAIL PROTECTED]
> > http://openid.net/mailman/listinfo/general
> >
> 
> 
> --
> Chris Messina
> Citizen Provocateur &
>   Open Source Ambassador-at-Large
> Work: http://citizenagency.com
> Blog: http://factoryjoe.com/blog
> Cell: 412 225-1051
> Skype: factoryjoe
> This email is:   [ ] bloggable[X] ask first   [ ] private
> 
> 
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

RE: [OpenID] Opened IPR Policy Draft

[Hallam-Baker, Phillip]

Don't worry about the patent trolls there is only one way to stop them and that 
is not to have any money worth stealing.

There are probably snots already reading the list archive so they can claim to 
have invented stuff. Someone claimed to have invented one IETF standard five 
years after the group started.

Fortunately the USPTO is slightly more selective these days and the publication 
period gives us a chance to try a new tactic: lets file a writ for perjury on 
the alleged inventors. Probably won't go anywhere but given the history its 
worth a try.


> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of David Nicol
> Sent: Monday, December 11, 2006 3:04 PM
> To: Gavin Baumanis
> Cc: specs@openid.net; Martin Atkins; [EMAIL PROTECTED]; 
> James A. Donald
> Subject: Re: [OpenID] Opened IPR Policy Draft
> 
> but the openID standard is more than a year old already.
> 
> On 12/10/06, Gavin Baumanis <[EMAIL PROTECTED]> wrote:
> > > So the technology is first proposed and described on this 
> list, on 
> > > 2006 December 7, 2006.  It is incorporated into the standard and 
> > > comes to be widely used around about, say, 2007 August.  On 2007 
> > > December 5, 2007, the patent troll has a friendly individual 
> > > inventor file an p! atent application claiming to have 
> invented the 
> > > technology on 2007, december 6.
> ___
> 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 IPR Policy Draft

[Hallam-Baker, Phillip]

Why not just take the W3C IPR policy verbatim and change the organization name?
 
The W3C patent policy is I believe released under creative commons for 
precisely this reason if not this can easily happen. The agreement was 
subscribed to by all the major vendors and the major open source groups.
 
Unless someone wants to incorporate proprietary technology that they are not 
willing to release the rights to as required by the W3C terms this is a debate 
we don't need to have.
 
 
Ideally the Apache, Mozilla, OASIS, W3C and IETF IPR WGs would get together and 
devise an industry standard acceptable to both Open Source and proprietary 
vendors. The introduction of suspense licenses means that it is not unthinkable 
that they would reach a common set of terms.

 



From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gabe 
Wachob
Sent: Thursday, December 07, 2006 1:01 PM
To: 'Brett McDowell'; Recordon, David
Cc: specs@openid.net; [EMAIL PROTECTED]
Subject: RE: OpenID IPR Policy Draft



Brett-

We need to get consensus on what the community wants before 
we take this to an attorney.. However, I've done these sorts of IPR policies 
for standards efforts several times and I can tell you that the process of 
working through these IPR policies is slow, painful and expensive. I think 
presenting an "already baked" (ie already drafted by lawyers) IPR policy to 
this community and asking for a up/down vote is not in keeping with the spirit 
of this development process. 

-Gabe

 





From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brett 
McDowell
Sent: Thursday, December 07, 2006 6:48 AM
To: Recordon, David
Cc: specs@openid.net; [EMAIL PROTECTED]
Subject: Re: OpenID IPR Policy Draft

 

This is normally lawyer work.  I recommend the companies & individuals 
invested in OpenID immediately turn this exercise over to your legal counsel to 
ensure your interests--and the interests of the community--are protected 
appropriately. 

Does the new OpenID organization have legal counsel retained (I don't 
mean volunteers, but actually hired)?  If not, that would be my second 
recommendation.

--Brett

On 12/6/06, Recordon, David <[EMAIL PROTECTED]> wrote:

Hey guys,
Been working with Gabe, and others, on starting to draft an IPR Policy
for OpenID specifications.  We'd appreciate feedback in terms of if what
is written captures the correct intent of the community?  We realize 
the 
language isn't technically as tight as it needs to be, though first want
to make sure it is saying the right thing.  It is largely based on the
IPR Policy for Microformats.

http://openid.net/wiki/index.php/IPR_Policy

Thanks,
--David
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs




-- 
Brett McDowell +1.413.662.2744 

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

RE: XRDS vs. DNS level identity (was RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers)

[Hallam-Baker, Phillip]

What you are calling discovery is what I would term location.

URL - Uniform Resource Locator

The locator is completely self contained, no discovery necessary, all the 
information you need to resolve is there. 

> -Original Message-
> From: Dick Hardt [mailto:[EMAIL PROTECTED] 
> Sent: Thursday, November 09, 2006 2:05 AM
> To: Johannes Ernst
> Cc: Hallam-Baker, Phillip; specs@openid.net; general
> Subject: Re: XRDS vs. DNS level identity (was RE: [PROPOSAL] 
> Handle "http://[EMAIL PROTECTED]" Style Identifiers)
> 
> I agree with Johannes here. DNS is not user accessible (for 
> good reason) Documents on a web server are relatively more accessible.
> 
> wrt. DNS, I think DNSSEC could have a significant role in 
> providing server to server discovery, specifically of key key 
> material.
> 
> -- Dick
> 
> On 8-Nov-06, at 8:00 PM, Johannes Ernst wrote:
> 
> > Just commenting on the XRDS discovery from HTTP URLs bit.
> >
> > Using DNS as a mechanism, given a URL, to discover the 
> location of, or 
> > obtain the content or equivalent of, the XRDS file, was 
> proposed back 
> > then in Yadis 0.x days, and rejected. The reason being that 
> any such 
> > mechanism would require the system administrator in charge 
> of the DNS 
> > system to "configure XRDS" for any and all users in that domain. It 
> > would give that system administrator an effective veto 
> (exercised by 
> > being lazy, for example) over whether or not users could 
> use OpenID on 
> > that domain, and in particular which services to reference 
> from that 
> > file (e.g. competitive services). There was general 
> consensus that for 
> > a "user-centric" identity system, that was not desirable, 
> and that's 
> > why we decided in favor of the HTTP header extension, its HTML 
> > equivalent, and the shortcut via the MIME type.
> >
> > We felt on safe ground with respect to naming design, because it's 
> > very much the same approach as, say, the reference of 
> embedded GIFs or 
> > CSS in HTML, or the use of URLs to identify DTDs in XML.
> >
> >
> > On Nov 8, 2006, at 17:19, Hallam-Baker, Phillip wrote:
> >
> >> Quite a few years went into the design of DNS.
> >>
> >> The concern I have here is that to influence the wider 
> network is a 
> >> very serious challenge.
> >>
> >> Innovation in naming is the single hardest thing to do in 
> a network 
> >> protocol. I have seen UDDI, Realnames, X.500, so many proposals.
> >>
> >>
> >> When someone tells me a simple thing is too complex and 
> then proposes 
> >> to do the single hardest, most complex thing in computer 
> networking I 
> >> have concerns.
> >>
> >>> -Original Message-
> >>> From: Drummond Reed [mailto:[EMAIL PROTECTED]
> >>> Sent: Wednesday, November 08, 2006 7:42 PM
> >>> To: Hallam-Baker, Phillip; Recordon, David; 'David Fuelling'
> >>> Cc: specs@openid.net; [EMAIL PROTECTED]
> >>> Subject: XRDS vs. DNS level identity (was RE: [PROPOSAL] Handle 
> >>> "http://[EMAIL PROTECTED]" Style Identifiers)
> >>>
> >>> Phillip,
> >>>
> >>> Please don't shoot me -- I am just the messenger -- but a 
> year-long 
> >>> effort
> >>> (Yadis) went into the design and deployment of XRDS 
> documents as the 
> >>> discovery infrastructure for OpenID.
> >>>
> >>> There are numerous reasons for this, but they boil down to
> >>> this: the XRDS layer of identity is rooted at a higher layer than 
> >>> that of DNS. Users don't just have DNS names in OpenID; they have 
> >>> URLs or XRIs. Those URLs or XRIs resolve to XRDS documents, which 
> >>> perform mapping of URLs/XRIs to URI-identified service endpoints. 
> >>> These service endpoint URIs in turn map down to services 
> resolvable 
> >>> at the DNS layer (which then of course map down to 
> machine addresses 
> >>> at the IP layer).
> >>>
> >>> I fully understand that you "have seen so many attempts 
> to reinvent 
> >>> it" (the DNS). OpenID and URL/XRI-based identity is not 
> an attempt 
> >>> to reinvent it. It is the emergence of identity 
> infrastructure at a 
> >>> higher layer designed to take advantage of the abstractions 
> >>> available at that layer, including:
> >>>
> >>> * URI and XRI syntax (much rich

RE: XRDS vs. DNS level identity (was RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers)

[Hallam-Baker, Phillip]

Quite a few years went into the design of DNS.

The concern I have here is that to influence the wider network is a very 
serious challenge.

Innovation in naming is the single hardest thing to do in a network protocol. I 
have seen UDDI, Realnames, X.500, so many proposals.


When someone tells me a simple thing is too complex and then proposes to do the 
single hardest, most complex thing in computer networking I have concerns.

> -Original Message-
> From: Drummond Reed [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, November 08, 2006 7:42 PM
> To: Hallam-Baker, Phillip; Recordon, David; 'David Fuelling'
> Cc: specs@openid.net; [EMAIL PROTECTED]
> Subject: XRDS vs. DNS level identity (was RE: [PROPOSAL] 
> Handle "http://[EMAIL PROTECTED]" Style Identifiers)
> 
> Phillip,
> 
> Please don't shoot me -- I am just the messenger -- but a 
> year-long effort
> (Yadis) went into the design and deployment of XRDS documents 
> as the discovery infrastructure for OpenID. 
> 
> There are numerous reasons for this, but they boil down to 
> this: the XRDS layer of identity is rooted at a higher layer 
> than that of DNS. Users don't just have DNS names in OpenID; 
> they have URLs or XRIs. Those URLs or XRIs resolve to XRDS 
> documents, which perform mapping of URLs/XRIs to 
> URI-identified service endpoints. These service endpoint URIs 
> in turn map down to services resolvable at the DNS layer 
> (which then of course map down to machine addresses at the IP layer).
> 
> I fully understand that you "have seen so many attempts to 
> reinvent it" (the DNS). OpenID and URL/XRI-based identity is 
> not an attempt to reinvent it. It is the emergence of 
> identity infrastructure at a higher layer designed to take 
> advantage of the abstractions available at that layer, including:
> 
> * URI and XRI syntax (much richer than DNS)
> * HTTP and HTTPS protocols for discovery
> * Extensible, XML-encoded resource description metadata
> * Mapping of reassignable and persistent identifiers for 
> persistent identity
> * Discovery of typed service endpoints
> 
> I know you know my personal bias (anyone who would push the 
> XRI boulder this long uphill has got to have a few screws 
> loose), but at this point it seems like trying to push the 
> XRDS layer back down into DNS would be like trying to put the 
> genie back in the bottle.
> 
> =Drummond 
> 
> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of Hallam-Baker, Phillip
> Sent: Wednesday, November 08, 2006 3:01 PM
> To: Recordon, David; David Fuelling
> Cc: specs@openid.net; [EMAIL PROTECTED]
> Subject: RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" 
> Style Identifiers
> 
> You can make things complex in two ways, one is by adding too 
> many curlicues to a design, another is by refusing to use the 
> deployed infrastructure for its intended purpose.
> 
> The signaling and discovery infrastructure of the Internet is the DNS.
> 
> I have seen so many attempts to reinvent it.
> 
> > -Original Message-
> > From: Recordon, David
> > Sent: Wednesday, November 08, 2006 4:50 PM
> > To: Hallam-Baker, Phillip; David Fuelling
> > Cc: specs@openid.net; [EMAIL PROTECTED]
> > Subject: RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" 
> > Style Identifiers
> > 
> > Involving DNS seems to make this too complex.  If we're going to 
> > involve DNS, we might as well re-architect Yadis to use it as yet 
> > another discovery option.
> > 
> > --David
> > 
> > -Original Message-
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] On Behalf Of Hallam-Baker, Phillip
> > Sent: Wednesday, November 08, 2006 1:37 PM
> > To: David Fuelling
> > Cc: specs@openid.net; [EMAIL PROTECTED]
> > Subject: RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" 
> > Style Identifiers
> > 
> > Please don't map to Http this way.
> > 
> > It would be fine to define a fixed mapping from a user 
> identifier to 
> > http. But it has to respect the http scheme design and be 
> crafted to 
> > avoid operability concerns.
> > 
> > http://example.com/user would be acceptable as meeting the scheme 
> > design. It is absolutely critical to maintain left/right hierarchy.
> > 
> > The username/password pieces in http were not well thought 
> out and may 
> > have to be eliminated.
> > 
> > 
> > The scheme I would propose would incorporate a policy 
> lookup so that 
> > it is possible to overide this mapping. The mapping to http 
> is fine as 
>

RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers

[Hallam-Baker, Phillip]

You can make things complex in two ways, one is by adding too many
curlicues to a design, another is by refusing to use the deployed
infrastructure for its intended purpose.

The signaling and discovery infrastructure of the Internet is the DNS.

I have seen so many attempts to reinvent it.

> -Original Message-
> From: Recordon, David 
> Sent: Wednesday, November 08, 2006 4:50 PM
> To: Hallam-Baker, Phillip; David Fuelling
> Cc: specs@openid.net; [EMAIL PROTECTED]
> Subject: RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" 
> Style Identifiers
> 
> Involving DNS seems to make this too complex.  If we're going 
> to involve DNS, we might as well re-architect Yadis to use it 
> as yet another discovery option.
> 
> --David 
> 
> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of Hallam-Baker, Phillip
> Sent: Wednesday, November 08, 2006 1:37 PM
> To: David Fuelling
> Cc: specs@openid.net; [EMAIL PROTECTED]
> Subject: RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" 
> Style Identifiers
> 
> Please don't map to Http this way.
> 
> It would be fine to define a fixed mapping from a user 
> identifier to http. But it has to respect the http scheme 
> design and be crafted to avoid operability concerns.
> 
> http://example.com/user would be acceptable as meeting the 
> scheme design. It is absolutely critical to maintain 
> left/right hierarchy.
> 
> The username/password pieces in http were not well thought 
> out and may have to be eliminated.
> 
> 
> The scheme I would propose would incorporate a policy lookup 
> so that it is possible to overide this mapping. The mapping 
> to http is fine as a last resort but making it the first 
> resort means we cannot ever change it.
> 
> What I would suggest is that we resolve [EMAIL PROTECTED] as follows
> 
> 1) Perform a DNS lookup for a TXT record at _openid.example.com
>   if found perform policy processing
> 
> 2) map the uri to http://example.com/user, do OpenID
> 
> 
> Policy processing:
> 
> The TXT record consists of a sequence of tag=value pairs that 
> list the authentication protocols that are supported. This 
> allows the relying party to choose the most appropriate 
> protocol for its needs.
> 
> For example:
> 
> "SAML=saml.example.com SAMLLite=saml.outsourced.com OPENID"
> 
> This says that the identity provider supports three different 
> authentication protocols, SAML, a reduced SAML and OPENID.
> 
> 
> > -Original Message-
> > From: David Fuelling [mailto:[EMAIL PROTECTED]
> > Sent: Wednesday, November 08, 2006 1:56 PM
> > To: Hallam-Baker, Phillip
> > Cc: specs@openid.net; [EMAIL PROTECTED]
> > Subject: RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" 
> > Style Identifiers
> > 
> > Hi Philip,
> > 
> > I'm not sure I understand "Please don't use HTTP this way".  
> > 
> > I was suggesting that the user enter an email address.  The RP then 
> > maps the email address to a URL (which would be in the 
> proper scheme).
> > 
> > 
> > > -Original Message-
> > > From: Hallam-Baker, Phillip [mailto:[EMAIL PROTECTED]
> > > Sent: Wednesday, November 08, 2006 1:45 PM
> > > To: David Fuelling; specs@openid.net
> > > Subject: RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style 
> > > Identifiers
> > > 
> > > Please don't use HTTP this way. That is not the semantics
> > for http URLs.
> > > 
> > > A better scheme would be to use mailto:[EMAIL PROTECTED] or
> > to define
> > > openid:[EMAIL PROTECTED]
> > > 
> > > 
> > > There are two issues here:
> > > 
> > > 1) The user presentation of the identifier
> > > 2) The machine presentation
> > > 
> > > The two do not need to be the same. www.cnn.com works
> > perfectly well
> > > as a way to locate CNN. That is a perfectly acceptable user 
> > > presentation. It is not an acceptable machine presentation and 
> > > browsers SHOULD NOT accept href="www.cnn.com".
> > > 
> > > 
> > > 
> > > 
> > > > -Original Message-
> > > > From: [EMAIL PROTECTED]
> > > > [mailto:[EMAIL PROTECTED] On Behalf Of David Fuelling
> > > > Sent: Wednesday, November 08, 2006 1:40 PM
> > > > To: specs@openid.net
> > > > Subject: RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]"
> > > > Style Identifiers
> > > >
> > > > 

RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers

[Hallam-Baker, Phillip]

Please don't map to Http this way.

It would be fine to define a fixed mapping from a user identifier to http. But 
it has to respect the http scheme design and be crafted to avoid operability 
concerns.

http://example.com/user would be acceptable as meeting the scheme design. It is 
absolutely critical to maintain left/right hierarchy.

The username/password pieces in http were not well thought out and may have to 
be eliminated.


The scheme I would propose would incorporate a policy lookup so that it is 
possible to overide this mapping. The mapping to http is fine as a last resort 
but making it the first resort means we cannot ever change it.

What I would suggest is that we resolve [EMAIL PROTECTED] as follows

1) Perform a DNS lookup for a TXT record at _openid.example.com
if found perform policy processing

2) map the uri to http://example.com/user, do OpenID


Policy processing:

The TXT record consists of a sequence of tag=value pairs that list the 
authentication protocols that are supported. This allows the relying party to 
choose the most appropriate protocol for its needs.

For example:

"SAML=saml.example.com SAMLLite=saml.outsourced.com OPENID"

This says that the identity provider supports three different authentication 
protocols, SAML, a reduced SAML and OPENID.


> -Original Message-
> From: David Fuelling [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, November 08, 2006 1:56 PM
> To: Hallam-Baker, Phillip
> Cc: specs@openid.net; [EMAIL PROTECTED]
> Subject: RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" 
> Style Identifiers
> 
> Hi Philip,
> 
> I'm not sure I understand "Please don't use HTTP this way".  
> 
> I was suggesting that the user enter an email address.  The 
> RP then maps the email address to a URL (which would be in 
> the proper scheme).
> 
> 
> > -Original Message-
> > From: Hallam-Baker, Phillip [mailto:[EMAIL PROTECTED]
> > Sent: Wednesday, November 08, 2006 1:45 PM
> > To: David Fuelling; specs@openid.net
> > Subject: RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style 
> > Identifiers
> > 
> > Please don't use HTTP this way. That is not the semantics 
> for http URLs.
> > 
> > A better scheme would be to use mailto:[EMAIL PROTECTED] or 
> to define 
> > openid:[EMAIL PROTECTED]
> > 
> > 
> > There are two issues here:
> > 
> > 1) The user presentation of the identifier
> > 2) The machine presentation
> > 
> > The two do not need to be the same. www.cnn.com works 
> perfectly well 
> > as a way to locate CNN. That is a perfectly acceptable user 
> > presentation. It is not an acceptable machine presentation and 
> > browsers SHOULD NOT accept href="www.cnn.com".
> > 
> > 
> > 
> > 
> > > -Original Message-
> > > From: [EMAIL PROTECTED]
> > > [mailto:[EMAIL PROTECTED] On Behalf Of David Fuelling
> > > Sent: Wednesday, November 08, 2006 1:40 PM
> > > To: specs@openid.net
> > > Subject: RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]"
> > > Style Identifiers
> > >
> > > Please see my questions/ideas enclosed...
> > >
> > > Thanks!
> > >
> > > David Fuelling
> > >
> > > > -Original Message-
> > > > From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] 
> > > > On Behalf Of Drummond Reed
> > > > Sent: Friday, October 20, 2006 1:04 AM
> > > > To: 'Recordon, David'; specs@openid.net
> > > > Subject: RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style 
> > > > Identifiers
> > > >
> > > > There have been several long threads in the past about 
> using email 
> > > > addresses as OpenID identifiers. The conclusion each time
> > > has been to
> > > avoid it. I don't remember all the arguments, but among them are:
> > > >
> > > > * Privacy: the last thing many users want to give a website
> > > is their
> > > > email address.
> > >
> > > This seems reasonable at first glance.  However, almost every 
> > > website I have a login with (today) requests my email address so 
> > > that the site can communicate with me electronically.
> > >
> > > So, if email addresses WERE used as an additional "login 
> input" for 
> > > OpenId, a user who didn't want to use his/her email 
> address to login 
> > > could always just use an IdP URL or XRI instead (as they 
> can today).
> > >
> > > Am I missing the 

RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers

[Hallam-Baker, Phillip]

Please don't use HTTP this way. That is not the semantics for http URLs.

A better scheme would be to use mailto:[EMAIL PROTECTED] or to define 
openid:[EMAIL PROTECTED]


There are two issues here:

1) The user presentation of the identifier
2) The machine presentation

The two do not need to be the same. www.cnn.com works perfectly well as a way 
to locate CNN. That is a perfectly acceptable user presentation. It is not an 
acceptable machine presentation and browsers SHOULD NOT accept 
href="www.cnn.com".


 

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of David Fuelling
> Sent: Wednesday, November 08, 2006 1:40 PM
> To: specs@openid.net
> Subject: RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" 
> Style Identifiers
> 
> Please see my questions/ideas enclosed...
> 
> Thanks!
> 
> David Fuelling
> 
> > -Original Message-
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On 
> > Behalf Of Drummond Reed
> > Sent: Friday, October 20, 2006 1:04 AM
> > To: 'Recordon, David'; specs@openid.net
> > Subject: RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style 
> > Identifiers
> > 
> > There have been several long threads in the past about using email 
> > addresses as OpenID identifiers. The conclusion each time 
> has been to
> avoid it. I don't remember all the arguments, but among them are:
> > 
> > * Privacy: the last thing many users want to give a website 
> is their 
> > email address.
> 
> This seems reasonable at first glance.  However, almost every 
> website I have a login with (today) requests my email address 
> so that the site can communicate with me electronically.  
> 
> So, if email addresses WERE used as an additional "login 
> input" for OpenId, a user who didn't want to use his/her 
> email address to login could always just use an IdP URL or 
> XRI instead (as they can today).
> 
> Am I missing the privacy concern here?  
> 
> > * Reassignability: email addresses are not only 
> reassignable, but for 
> > some domains, they are notoriously short-lived identifiers.
> 
> Is this really such a problem?  It seems to exist for URL's 
> in the current protocol proposal anyway.  For instance, most 
> people don't own a Domain, which means they'll be using 
> OpenID URL's that somebody else owns.  Thus, URL's are 
> reassignable too, and suffer from this in the same way 
> (although I don't really see this as a problem).
> 
> > * Non-portability: unless you own the top-level domain, they aren't 
> > portable.
> 
> Again, is this a problem if the email isn't the actual 
> identifier?  If we have a means of mapping an email to an 
> OpenID Identity URL, then if the email goes away (is 
> transferred or otherwise not in the control of the original 
> user), then what's the problem?
> 
> Point 1.) Losing an email address is no different than the 
> case where a URL is lost/transferred/goes away.
> 
> Point 2.) If a user "lost" his email address, theoretically 
> the owner of the email address (example.com, e.g.) would 
> remove the mapping from [EMAIL PROTECTED] to beth's Identity 
> Provider URL.
> 
> Point 3.) Even if the email address domain owner failed to 
> remove this mapping, only the end-user (beth in this case) 
> would be using the email to login.  Presumably, if she 
> switched email addresses, she would use her new address to 
> login, and it wouldn't matter.  Somebody else trying to use 
> her email address would need to login to the IdP, and 
> presumably be stopped there.
> 
> > Food for thought...
> > 
> > =Drummond
> 
> 
> ___
> 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: Making identities persistent?

[Hallam-Baker, Phillip]

I'm afraid I still don't get it.

As far as I am concerned the authenticated identifier is the tuple:

   (Identity-provider-Id,  Identifier)

If we want to have a single identifier there has to be a mechanism for 
establishing the scope of authority for each IdP over a specific subset of 
identifiers.

There are only two potential mechanisms I can see for achieving this:

  1) A lexigraphical convention
  2) A signalling registry


> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of Pete Rowley
> Sent: Wednesday, November 01, 2006 1:53 PM
> To: Rowan Kerr
> Cc: specs@openid.net
> Subject: Re: Making identities persistent?
> 
> Rowan Kerr wrote:
> > On Wed, 2006-11-01 at 11:33 -0500, John Kemp wrote:
> >   
> >> I think you need the ability for a user to change his 
> identifier at 
> >> the RP (as George notes below) and also at the IdP.
> >> 
> >
> > Isn't this was already covered in the spec? You accomplish this by 
> > creating an HTML page on some website you control with a http-equiv 
> > meta tag in it that points to your IdP. Then you use your 
> own url as 
> > your Identity, even though ultimately the data is pulled 
> from the IdP.
> >
> > So if you ever want to change IdP's you simply update your 
> html page 
> > with the new server. And your Identifier never needs to change.
> >
> >
> >   
> Except that the spec specifies that it is the derived 
> identifier of the IdP that is used at the RP - which means a 
> delegated identifier actually isn't used as an identifier. 
> That is not quite the same thing.
> 
> --
> Pete
> 
> 
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

RE: Making identities persistent?

[Hallam-Baker, Phillip]

Don't forget that the a more important constraint here is to prevent 
impersonation.

I don't see how one can switch between genuinely autonamous IdPs in the way 
suggested without allowing a rogue IdP to impersonate anyone they chose.

At what point do the synchronization mechanisms you build in exceed the 
complexity of PKI?

> -Original Message-
> From: John Kemp [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, November 01, 2006 11:33 AM
> To: Hallam-Baker, Phillip
> Cc: Stefan Görling; Shutra Zhou; specs@openid.net
> Subject: Re: Making identities persistent?
> 
> Hello,
> 
> I think you need the ability for a user to change his 
> identifier at the RP (as George notes below) and also at the 
> IdP. In addition, it should be possible for the IdP to 
> providing OpenID "forwarding" if the user leaves for another 
> IdP (perhaps the user will even pay for a forwarding
> service?)
> 
> We're not talking about persistence as such (a particular 
> users OpenID can surely change over time?), but more the 
> ability for the user to update her OpenID when she switches 
> from one IdP to another. At the IdP, this would I guess be 
> kind of like leaving a forwarding address, as the user is 
> "leaving" one IdP and moving to another. At the RP, the user 
> is telling the RP that he is using a new IdP.
> 
> So, I think George's (1) is a necessity, and agree that (2) 
> is a business decision, but certainly offers the ability for 
> an IdP to be "community-friendly" if it so wishes, and may 
> even be a good business decision.
> 
> Isn't this all about the likely /lack/ of persistence in a 
> particular OpenID though?
> 
> Regards,
> 
> - John
> 
> Hallam-Baker, Phillip wrote:
> > If we want identities to be persistent then we are going to need to 
> > introduce a layer of indirection.
> > 
> > This normally gets me worried about patents and such. Fortunately 
> > Multics did this, so did UNIX and VMS. Plenty of prior art.
> > 
> > If we are serious about decentralization then map the user 
> identifier 
> > onto a randomly assigned machine readable GUID.
> > 
> >> -Original Message- From: [EMAIL PROTECTED] 
> >> [mailto:[EMAIL PROTECTED] On Behalf Of Stefan Görling Sent:
> >> Wednesday, November 01, 2006 10:52 AM To: Shutra Zhou Cc:
> >> specs@openid.net Subject: Re: Making identities persistent?
> >> 
> >> 
> >> The reasons for raising this question was partly that I've 
> been doing 
> >> some research on how people use e-mail addresses and sad 
> to say, you 
> >> can not expect the user to make wise choices. And even so, 
> companies 
> >> go broke even the best ones. Services comes and disappear. In my 
> >> research over half of the population use non-portable e-mail 
> >> addresses tied to an employer, university, etc.
> >> and is likely to only live a few years.
> >> 
> >> E-mail is not a stable address/identity identifier. We 
> must not rely 
> >> on it as such.
> >> 
> >> If we want an identity to be persistent, it must contain a 
> migration 
> >> feature, so that I can move all their trust relations from 
> one place 
> >> to another. This of course creates a number of other 
> issues such as 
> >> security and complexibility, but it is my sincere belief that the 
> >> issue should be addressed by the system and not only 
> delegated to be 
> >> dependent on wise user decisions.
> >> 
> >> Therefore, my +1 is on (1) below. I will try to read back 
> on what has 
> >> been said in the past on a 'change identifier' extension 
> and see if 
> >> there is anything I can do to help.
> >> 
> >> /Stefan
> >> 
> >>> Yes, this is important thing I thought. We should privide a
> >> spec for
> >>> the consumer to change their end user's OpenID URL,
> >> optionally the end
> >>> user can use multiple OpenIDs in this consuemr. And this
> >> case can be
> >>> expended as this, the IdP（OpenID Server） is closed down.
> >>> 
> >>> 2006/10/31, George Fletcher <[EMAIL PROTECTED]
> >> <mailto:[EMAIL PROTECTED]>>:
> >>> This is a good use case and I think important for both users and 
> >>> IdPs (now OPs [OpenID Provider] per the latest "editor's
> >>> conference") to consider.
> >>> 
> >>> I see a number of options...
> >>> 
> >>> 1. There has been

RE: Making identities persistent?

[Hallam-Baker, Phillip]

If we want identities to be persistent then we are going to need to introduce a 
layer of indirection. 

This normally gets me worried about patents and such. Fortunately Multics did 
this, so did UNIX and VMS. Plenty of prior art. 

If we are serious about decentralization then map the user identifier onto a 
randomly assigned machine readable GUID.

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of Stefan Görling
> Sent: Wednesday, November 01, 2006 10:52 AM
> To: Shutra Zhou
> Cc: specs@openid.net
> Subject: Re: Making identities persistent?
> 
> 
> The reasons for raising this question was partly that I've 
> been doing some research on how people use e-mail addresses 
> and sad to say, you can not expect the user to make wise 
> choices. And even so, companies go broke even the best ones. 
> Services comes and disappear. In my research over half of the 
> population use non-portable e-mail addresses tied to an 
> employer, university, etc. and is likely to only live a few years.
> 
> E-mail is not a stable address/identity identifier. We must 
> not rely on it as such.
> 
> If we want an identity to be persistent, it must contain a 
> migration feature, so that I can move all their trust 
> relations from one place to another. This of course creates a 
> number of other issues such as security and complexibility, 
> but it is my sincere belief that the issue should be 
> addressed by the system and not only delegated to be 
> dependent on wise user decisions.
> 
> Therefore, my +1 is on (1) below. I will try to read back on 
> what has been said in the past on a 'change identifier' 
> extension and see if there is anything I can do to help.
> 
> /Stefan
> 
> > Yes, this is important thing I thought. We should privide a 
> spec for 
> > the consumer to change their end user's OpenID URL, 
> optionally the end 
> > user can use multiple OpenIDs in this consuemr. And this 
> case can be 
> > expended as this, the IdP（OpenID Server） is closed down.
> >
> > 2006/10/31, George Fletcher <[EMAIL PROTECTED] 
> >:
> >
> > This is a good use case and I think important for both users and
> > IdPs (now OPs [OpenID Provider] per the latest "editor's
> > conference") to consider.
> >
> > I see a number of options...
> >
> > 1. There has been some discussion regarding a "change 
> identifier"
> > extension that would allow you to change your identifier at the
> > relying party.  This would solve the use case and is necessary
> > regardless of the other options.
> >
> > 2. The OP (in this case AOL.com) could continue to provide an
> > "identifier management" page that would allow the user 
> to specify
> > the OP of choice.  This requires the OP to continue to serve the
> > XRDS doc or at least the indirection to a XRDS doc with the new
> > OP.  This is not that much extra overhead for the OP, 
> but it will
> > likely be a business decision as to whether to support 
> such a feature.
> >
> > 3. The user gets to choose their OP so they can ensure that they
> > don't get "locked in".  This is the ideal behind user-centric. 
> > However, in practice, it will take good education and time for
> > users to understand the ramifications of their decisions.
> >
> > Thanks,
> > George
> >
> > Stefan Görling wrote:
> >
> >>Hi everybody,
> >>
> >>I'm trying to get a grip around your great work and have one issue 
> >>that I'm not quite clear on, relevant to the discussion of using
> >>
> >>[EMAIL PROTECTED]  
> identifiers, but also in a more general context. 
> >>Please let me know if I've simply missunderstood my own question.
> >>
> >>
> >>http://openid.net/specs/openid-authentication-2_0-09.html#an
chor48 says:
> >>"OpenID is decentralized. No central authority must approve or 
> >>register Relying Parties or Identity Providers. An End User 
> can freely 
> >>choose
> >>
> >>which Identity Provider to use. They can preserve their 
> Identifier if 
> >>they switch Identity Providers."
> >>
> >>Let us consider the case that I'm an AOL.com customer, and 
> they act as 
> >>an IdP providing we with an identifier. I use this identifier for 3
> >>
> >>years for identity management on most of the services I use, due to 
> >>the huge success of the standard... However, I'm starting 
> to get fed 
> >>up with AOL and terminates my agreement with them. Is there any 
> >>procedure for me
> >>
> >>to switch to another IdP? How is this done?
> >>
> >>Best Regards,
> >>
> >>Stefan Görling
> >>
> >>
> >>
> >>___
> >>specs mailing list
> >>
> >>specs@openid.net  
> >>http://openid.net/mailman/listinfo/specs
> >>
> >>  
> >>
> >
> > ___
> > specs mailing list
> > specs@openid.net 
> > http://openid.net/mailman/

RE: Making identities persistent?

[Hallam-Baker, Phillip]

Bad statement of the principle. Centralized direction is 
inevitable if there are to be unique, mnemonic 
identifiers.
 
The questions are whether the centralized control is 
accountable, whether the system has checks and balances and the confidence that 
users can place in the registry continuing to be supported after the startup 
money has run out.
 
 


  
  
  From: [EMAIL PROTECTED] 
  [mailto:[EMAIL PROTECTED] On Behalf Of Drummond 
  ReedSent: Tuesday, October 31, 2006 10:31 PMTo: 'George 
  Fletcher'; 'Stefan Görling'Cc: specs@openid.netSubject: 
  RE: Making identities persistent?
  
  
  Good answer, George. 
  The question applies mainly to delegated identifiers (e.g., email addresses 
  delegated under a specific DNS domain like [EMAIL PROTECTED], third-or-lower level 
  domain names like user.aol.com, or community i-names such as @aol*user), since 
  they are by definition assigned within the context of (and thus under the 
  ultimate control of) as specific identifier community (such as aol.com). 
  
   
  For identifiers 
  registered directly with a global registry (e.g., joesmith.com in DNS or 
  =joe.smith in XRI), the identifiers themselves are portable across registrars 
  and the registrant has direct control of the identifier and what it resolves 
  to (e.g., the XRDS document).This portability is established by ICANN for DNS 
  registries and XDI.org for XRI global registries.
   
  So the section of the 
  spec you cite should probably be clarified with regard to these points, i.e., 
  something like: 
   "OpenID is decentralized. No central authority must approve or register Relying Parties or OpenID Providers. An End User can freely choose which OpenID Provider to use. OpenID design also enables an End User to continue to use an OpenID Identifier if they switch OpenID Providers. Note that the portability and persistence of an OpenID identifier itself (URL or XRI) is a capability of the identifier and the registry authority and is out of scope for OpenID. End Users who wish to maintain persistent control of an OpenID Identifier SHOULD select an identifier and registry authority that offers these capabilities.”
   
  Thoughts?
   
  =Drummond 
  
  
  
  
  
  From: 
  [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of George FletcherSent: Tuesday, October 31, 2006 7:36 
  AMTo: Stefan 
  GörlingCc: 
  specs@openid.netSubject: Re: 
  Making identities persistent?
   
  This is a good use case and I 
  think important for both users and IdPs (now OPs [OpenID Provider] per the 
  latest "editor's conference") to consider.I see a number of 
  options...1. There has been some discussion regarding a "change 
  identifier" extension that would allow you to change your identifier at the 
  relying party.  This would solve the use case and is necessary regardless 
  of the other options.2. The OP (in this case AOL.com) could continue 
  to provide an "identifier management" page that would allow the user to 
  specify the OP of choice.  This requires the OP to continue to serve the 
  XRDS doc or at least the indirection to a XRDS doc with the new OP.  This 
  is not that much extra overhead for the OP, but it will likely be a business 
  decision as to whether to support such a feature.3. The user gets to 
  choose their OP so they can ensure that they don't get "locked in".  This 
  is the ideal behind user-centric.  However, in practice, it will take 
  good education and time for users to understand the ramifications of their 
  decisions.Thanks,GeorgeStefan Görling wrote: 
  Hi everybody, I'm trying to get a grip around your great work and have one issue that I'm not quite clear on, relevant to the discussion of using [EMAIL PROTECTED] identifiers, but also in a more general context. Please let me know if I've simply missunderstood my own question. http://openid.net/specs/openid-authentication-2_0-09.html#anchor48 says:"OpenID is decentralized. No central authority must approve or register Relying Parties or Identity Providers. An End User can freely choose which Identity Provider to use. They can preserve their Identifier if they switch Identity Providers." Let us consider the case that I'm an AOL.com customer, and they act as an IdP providing we with an identifier. I use this identifier for 3 years for identity management on most of the services I use, due to the huge success of the standard... However, I'm starting to get fed up with AOL and terminates my agreement with them. Is there any procedure for me to switch to another IdP? How is this done? Best Regards, Stefan Görling   ___specs mailing listspecs@openid.nethttp://openid.net/mailman/listinfo/specs   
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers

[Hallam-Baker, Phillip]

No, that is the work-arroundThe solution is 
to have the email client assign fonts according to who 
is writing. 
Messages from Lord 
Rees-Mogg are written in an elegant Edwardian Copperplate. 
Paris Hilton uses 
BroadwayComments from Dick come in this 
font
Sounds right to 
me.
> -Original Message-> From: 
[EMAIL PROTECTED]> [mailto:[EMAIL PROTECTED]] On 
Behalf Of Dick Hardt> Sent: Sunday, October 22, 2006 5:00 PM> To: 
Kaliya Hamlin> Cc: specs@openid.net> Subject: Re: [PROPOSAL] 
Handle "http://[EMAIL PROTECTED]"> 
Style Identifiers>>> On 22-Oct-06, at 12:43 PM, Kaliya 
Hamlin wrote:>> > For starters please don't use Comic Sans in 
professional> > correspondence. it is very hard to read (or take 
seriously)>  http://> > 
bancomicsans.com/home.html>> Kaliya: The easy solution is to have 
your email program turn> all responses to plain text. :-)> 
___> 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: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers

[Hallam-Baker, Phillip]

Wouldn't it be nice if we could just bypass all the stupid email callback stuff 
that we usually have to put up with?

Its easy to do, the only constraint being that the IdP has to be able to 
advertise an SRV record.

IdP advertises 

_openid.example.com  SRV 1 100 80 openid1.example.com


Given an identifier [EMAIL PROTECTED] the RP looks for the _openid service, 
resolves this works out where to resolve the URI. 

This does not have to be the only mode of resolution but it is certainly a very 
very useful one and something that can be used transparently inline with 
existing practice. Many sites already use the email address form as an 
identifier.

Of course there is a spam issue, there is a spam issue with every contact 
identifier. That's why you use the IdP account and don't muck up your email 
account.



> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of Dick Hardt
> Sent: Sunday, October 22, 2006 11:14 PM
> To: George Fletcher
> Cc: specs@openid.net
> Subject: Re: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" 
> Style Identifiers
> 
> 
> On 22-Oct-06, at 7:00 PM, George Fletcher wrote:
> 
> >
> >
> > Dick Hardt wrote:
> >> With OpenID, there is a presumption the user has selected a trust 
> >> worthy IdP that  will only present the user's identifiers when it 
> >> really is the user.
> >>
> > Doesn't this imply that both the user and RP have to know 
> which IdP's 
> > are "trust worthy"?
> 
> It is a choice by the user. Just like the user chooses with 
> ISP to move their data, which browser to run, which OS to 
> run. IN general, those are not dictated by the RP.
> 
> >> Actually, idp.spammers.com cannot do that. The URL has 
> metadata that 
> >> states which IdP(s) are authoritative. What 
> idp.spammers.com can do 
> >> is flood an RP with a bunch of identifiers. But this is no 
> different 
> >> then a script creating new accounts on a system and is 
> defended using 
> >> the same mechanisms such as throttling and captchas.
> >>
> > So why can't idp.spammers.com allow anyone to enter a URI of 
> > http://idp.spammers.com/ that resolves to a valid 
> XRDS document.
> > The RP then follows the IdP service link back to 
> > https://idp.spammers.com and does the association exchange. 
>  Now the 
> > RP re-directs the user to https://idp.spammers.com for the 
> login page, 
> > which just re-directs the user back to the RP with the valid 
> > "assertion"
> > fields. idp.spammers.com does not have to ask the user for 
> > authentication credentials (that is out of scope for the 
> spec).  For 
> > commenting on blogs this would be similar to "bugmenot" for web 
> > subscription services.
> >
> > So of course, the RP just needs to "blacklist" 
> idp.spammers.com.  But 
> > now we are back in the same situation we have today where 
> its a race 
> > between spammers setting up "IdPs" and RPs "black-listing" them.
> 
> I don't understand why the RP needs to do that ... is the RP 
> wanting to do something it can't do today?
> 
> >
> > Fundamentally, "trust worthiness" is paramount to making the system
> > work.  For now, this means RPs will likely have some sort of ACL  
> > (black
> > or white) for the IdPs that they deal with.
> 
> The "trust" I am referring to is the user "trusting" the IdP to not  
> let someone else impersonate them.
> 
> George: would you explain what problem you are wanting to solve so  
> that we can deal with a concrete example? There are use cases OpenID  
> solves today, and others require additional features that currently  
> are not in the specification.
> 
> -- Dick
> 
> ___
> 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: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers

[Hallam-Baker, Phillip]

This all depends on whether OpenIDs are going to be used 
exclusively as hooks for attributes or as a contact 
mechanism.
 
I think that there will inevitably be demand to use the 
identifiers as contact addresses. The question is how this need is going to be 
met in a way that prevents people being spammed to death.
 
I don't see how anyone is going to pay to be =drummond if 
they are the only person who is ever going to type the text in. The idea makes 
no sense since anyone who cares about what they type in can get a plug in that 
provides a pretty name for free.
 
 
Ergo we are talking about contact addresses and on the 
Internet that means email addresses. I am willing to watch people spend 
large amounts of money attempting to prove otherwise. I am not going to throw 
roadblocks in their way to the tar pit. 
 
All I want is the ability to say to people 'I told you so' 
afterwards. 
 
And to offer email addresses on an equal basis with XRIs. 
In other words I am quite happy for others to jump into what I believe to be a 
tar pit and splash around. What I object to is being tied to 
them.
 

  
  
  From: [EMAIL PROTECTED] 
  [mailto:[EMAIL PROTECTED] On Behalf Of John 
  PanzerSent: Friday, October 20, 2006 3:17 PMTo: Kaliya 
  *Cc: specs@openid.netSubject: Re: [PROPOSAL] Handle 
  "http://[EMAIL PROTECTED]" Style Identifiers
  Kaliya * 
  wrote on 10/20/2006, 11:57 AM: 
  
  I think it is a terrible 
idea.1) If you put something out into the market that looks like an 
e-mail it will be used like an e-mail. I have personal experience with this. 
I had a AIM handle for the Mac part of the universe [EMAIL PROTECTED] (it was not an e-mail 
address) but because it looked like one people used it like one and I 
basically had to go to .mac and pay for an account so that the wires did not 
cross. This came 
  out of the discussions we have about a smooth migration path for our users at 
  AOL.  In our case the [EMAIL PROTECTED] nickname is also a 
  resolvable email address, though it may not be the primary mail account of the 
  user.  I'd suggest that as a best practice, anywhere that a [EMAIL PROTECTED] nickname is used, it 
  should also be a resolvable email address.  And there should always be an 
  option to not use something that looks like an email 
address.
  2) I think OpenID is new and 
needs a new way to identify folks. And it is our job to teach people about 
this new way.  Lots of services give people homepages within their 
spaces...myspace, AIMpages etc.  so they can use those URL's if they 
don't have one yet they can get one. There's a bootstrapping problem here.  It's very, 
  very hard to promote the use of something that requires a more complex login 
  flow to replace something that is very simple (albeit limited and in its own 
  silo).  How can we cross this chasm?  Our suggestion is to support 
  existing practice of [EMAIL PROTECTED] in a standard way, while 
  being open to new practices.  Once we can support both we can gain 
  experience and start gradually migrating people over to the new world.  
  At least that's my take.-- John PanzerSystem Architecthttp://abstractioneer.org
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers

[Hallam-Baker, Phillip]

Back at the dawn of the Web I made the mistake of thinking that the address bar 
was the place you type a URI.

We now know that it is the place you type a search term that may be a URL in 
canonical form or may be a domain name or may be a search term to be thrown at 
a search engine. It was one of the principle innovations in Netscape over 
Mosaic.

Any identifier can be represented as a URI. Just stick SCHEME: in front.


> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of Recordon, David
> Sent: Thursday, October 19, 2006 9:46 PM
> To: specs@openid.net
> Subject: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers
> 
> In meeting with a large service provider this week, an issue 
> around end user usability came up.  The concern they 
> expressed was that users are know how to enter usernames or 
> email addresses to initiate the login process.  While 
> directed identity allows the user to enter "example.com", 
> they feel that it still is a bit of a stretch at this time 
> for any major deployment of OpenID.
> 
> The proposal we came up with was within the spec describing 
> what to do if someone were to enter "[EMAIL PROTECTED]" in a 
> Relying Party's OpenID login form.  The idea is that the RP 
> splits the string on the "@" and then treats "example.com" as 
> the IdP Identifier.  This thus doesn't actually require any 
> changes to the protocol itself.  Any Relying Party can do 
> this today, but they desire to see this as part of the 
> specification itself so they wouldn't be doing anything special.
> 
> Within the 
> http://www.lifewiki.net/openid/ConsolidatedDelegationProposal
> proposal, in case one, openid.identity would be set to 
> "http://openid.net/identifier_select/2.0"; and then instead of 
> openid.portable being empty, in this case "[EMAIL PROTECTED]" 
> would be sent to the IdP.  While not perfectly mapping to the 
> definition of the openid.portable field, it doesn't seem like 
> that much of a hack to do this.
> 
> While I certainly am not looking to re-kindle the "Why a 
> URI?" debate, http://[EMAIL PROTECTED] is also technically a 
> valid URI.  It is used in many cases by browsers to provide a 
> username when making a web request.
> 
> So while this is a little funky, I really think the increased 
> usability offered by describing what a RP should do when a 
> string like this is entered seems to outweigh the potential 
> conceptual confusion.
> 
> Thoughts?
> 
> --David
> ___
> 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: Identifier portability: the fundamental issue

[Hallam-Baker, Phillip]

Title: RE: Identifier portability: the fundamental issue






We must have different understandings of the term sacred then.

My understanding of the term is that it refers to a tenet of faith which might cause offense if contradicted.




Sent from my GoodLink Wireless Handheld (www.good.com)

 -Original Message-
From:   Drummond Reed [mailto:[EMAIL PROTECTED]]
Sent:   Friday, October 13, 2006 12:58 PM Pacific Standard Time
To: specs@openid.net
Subject:    Identifier portability: the fundamental issue

Yesterday we established consensus that with OpenID, identifier portability
is sacred.

Today I'd like to establish consensus on the following "postulate":

"To achieve identifier portability in OpenID, it MUST be possible for the RP
and the IdP to identify the user using two different identifiers: an
identifier by which the RP knows the user (the portable identifier), and an
identifier by which the IdP knows the user (the IdP-specific identifier)."

I would submit that if this postulate is true, then OpenID Authentication
2.0 requires two identifier parameters because if the protocol only allows
sending one, then:

1) If the RP sends the IdP-specific identifier, the RP must keep state to
maintain mapping to the portable identifier (bad), and

2) If the RP sends the portable identifier, an IdP is forced to do a
resolution a second time after the RP has already done resolution (bad).

OTOH, if the postulate is false, then a case can be made for OpenID
Authentication 2.0 having just one identifier parameter.

PROOF

CASE 1: the protocol supports only IdP-specific identifiers and no portable
identifiers.

RESULT: IdPs can achieve identifier lockin. Not acceptable. End of Case 1.

CASE 2: the protocol supports only portable identifiers and no IdP-specific
identifiers.

RESULT: IdP is forced to know and store all portable identifiers for a user,
including identifiers for which the IdP is not authoritative, and users
would be forced to register all their portable identifiers with their IdP,
and to update these registrations every time the user adds or deletes a
portable identifier. Highly undesirable if not impossible.

*

Please post if you do not agree with this postulate.

=Drummond





___
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: Delegation discussion summary

[Hallam-Baker, Phillip]

Title: RE: Delegation discussion summary






There is an established vocabulary, it should be used.

Sent from my GoodLink Wireless Handheld (www.good.com)

 -Original Message-
From:   Recordon, David [mailto:[EMAIL PROTECTED]]
Sent:   Thursday, October 12, 2006 09:04 PM Pacific Standard Time
To: Gabe Wachob; Graves, Michael; specs@openid.net
Subject:    RE: Delegation discussion summary

I'd have to agree with Gabe about this, let's get it done! :)


 -Original Message-
From:   Gabe Wachob [mailto:[EMAIL PROTECTED]]
Sent:   Thursday, October 12, 2006 05:43 PM Pacific Standard Time
To: Graves, Michael; specs@openid.net
Subject:    RE: Delegation discussion summary

*If* we are going to open up the terminology discussion, for me the terms
"authenticating party" (formerly the "IDP") and "accepting party" (formerly
the "relying party") seem more descriptive.  The authenticating party issues
authentication assertions in the form of special HTTP request/responses with
the other party, who then accepts these assertions and decides whether or
not they are good enough to let a user do something.

As far as Dick's terminology, I'm not sure how "membersite" makes sense
here. Perhaps it's a matter of history or perspective that I haven't been
enlightened on.

In any case, I'd rather get openid 2.0 out sooner than have a long
discussion on terminology, so I won't push this any further unless someone
else really thinks its valuable.

    Gabe

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf
> Of Graves, Michael
> Sent: Thursday, October 12, 2006 5:00 PM
> To: specs@openid.net
> Subject: RE: Delegation discussion summary
>
> Josh, et al,
>
> I believe the first of your options --  "Both portable and IdP-specific
> identifiers" -- is the superior choice here. It preserves OpenID 1
> semantics, and unambiguously makes room for portable identifiers. I
> don't see the added burden carried by relying party code for this option
> viz. portable identifiers only as being significant. Recommend we
> proceed with the "both" strategy.
>
> Also, this may be throwing a wrench in the gears here, but I'd like to
> toss in the idea of using this point in time to pivot on our terminology
> and look at adopting Dick Hardt's terminology here. Portable identifiers
> are a powerful upgrade in and of themselves, and get us off the "IDP
> lock-in" hook that I've been hung up with customers on now a couple
> times. But as we move away from explicit IdP-specific URLs as the only
> identifier, I think that the Sxip "homesite" model becomes more
> important to consider as well. I very much like the idea of entiring in
> my "homesite" URL at a participating "membersite" (OpenID relying
> party), say "http://myidmanager.com" and during the authentication
> process, being able to choose from one of n available personae managed
> for me by myidmanager.com. So my "final" identifier may be
> "http://myidmanager.com/73648729" or even "http://graves.isnuts.com".
>
> I won't delve into where we are with respect to that capability here,
> but want to suggest that maybe as we move to OpenID 2.0, and now offer
> portable IDs (as well as run-time chosen IDs selected at auth-time?), we
> may be wise to just make the jump to using "homesite" and "membersite"
> across the board, rather than "IdP" and "relying party", both of which
> are technically problematic for our framework.
>
> Anyway, that's a bit off topic, but something to consider.
>
> In any case, the "both" option below gets my vote.
>
> Good work Josh!
>
> -Mike
>
>
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On
> Behalf Of Josh Hoyt
> Sent: Thursday, October 12, 2006 12:29 PM
> To: specs@openid.net
> Subject: Delegation discussion summary
>
> Hello, list,
>
> I'm sure that another message in your inbox with "delegation" in the
> title makes most of you cringe, so I'm sorry for that.I hope that this
> one gets us closer to resolving this issue.
>
> I have attempted to summarize the proposed delegation mechanisms, as
> well as the currently-specified delegation mechanism in a single
> document. I have glossed over some issues and left out some of the
> discussion, but I hope that I captured most of the important stuff.
> After reviewing the discussion, I think that we are actually pretty
> close to consensus on a course of action.
>
> I have added one new thing in this write-up, which is that I have
> started calling "delegation" "portable identifier support", which gives
> rise to the term "portable identifier" for what is currently called a
> "delegated identifier." I think that this terminology is a little easier
> to understand and less loaded than calling it "delegation."
>
> My write-up follows.
>
> Josh
>
> OpenID portable identifier support
> ##
>
> Portable identifier support allows an IdP to do authentication for an
> identifier that was not