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

2008-10-30 Thread 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 than the OpenID information 

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

2008-10-30 Thread 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 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'd be happy to hear it. I don't claim to be a DNS expert. However, it'd
take a very convincing argument for me to get behind anything that
requires something other than A, CNAME, MX and TXT records though, for
the reasons stated

RE: OpenID Email Discovery

2008-01-04 Thread Hallam-Baker, Phillip
 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

2008-01-04 Thread 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

2008-01-04 Thread 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

2008-01-03 Thread 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 Email Discovery

2008-01-03 Thread 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 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

___
specs mailing list
specs@openid.net
http

RE: Wiki page: Attempting to document the Email Address as OpenIddebate.

2007-02-12 Thread 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 OpenIddebate.
 
 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: [OpenID] Wiki page: Attempting to document the Email Address asOpenId debate.

2007-02-12 Thread 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: [OpenID] Wiki page: Attempting to document the Email Addressas OpenIddebate.

2007-02-12 Thread 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: Proposal: An anti-phishing compromise

2007-02-01 Thread 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@openid.net
 http://openid.net/mailman/listinfo/specs
 
___
specs mailing list
specs@openid.net

RE: OpenID Auth 2.0 security considerations

2007-01-23 Thread 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

2007-01-22 Thread 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: [OpenID] Announcing OpenID Authentication 2.0 - Implementor'sDraft 11

2007-01-22 Thread 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

2007-01-22 Thread 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] Opened IPR Policy Draft

2006-12-12 Thread 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

2006-12-11 Thread 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] Opened IPR Policy Draft

2006-12-11 Thread 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 IPR Policy Draft

2006-12-07 Thread 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: [PROPOSAL] Handle http://[EMAIL PROTECTED] Style Identifiers

2006-11-08 Thread 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: [PROPOSAL] Handle http://[EMAIL PROTECTED] Style Identifiers

2006-11-08 Thread 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 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

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

2006-11-08 Thread 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 
  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

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

2006-11-08 Thread 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 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

RE: Making identities persistent?

2006-11-01 Thread 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] 
 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 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] mailto:[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 mailto:specs@openid.net 
 http://openid.net/mailman/listinfo/specs
 
   
 
 
  ___
  specs mailing list
  specs@openid.net mailto: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

RE: Making identities persistent?

2006-11-01 Thread 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: [PROPOSAL] Handle http://[EMAIL PROTECTED] Style Identifiers

2006-10-23 Thread Hallam-Baker, Phillip



No, that is the work-arroundThe solution is 
to have theemail 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

2006-10-19 Thread 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: Delegation discussion summary

2006-10-13 Thread 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 issued by that IdP. It has two motivating use
 cases [1]_:

 * allow users to use any identifier with any IdP

 * allow users to move an identifier between IdPs (prevent 

RE: Identifier portability: the fundamental issue

2006-10-13 Thread 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