RE: OpenID Email Discovery

2008-01-04 Thread Gabe Wachob
I'm sorry, Phillip, we're not going to let you get away with that one. 

 

Drummond already asked you about what you are talking about w/r/t IPR
commitments, and I haven't seen a reply. All IPR commitments for XRI are in
place and have been for quite a while. I encourage you to review the RF on
Limited Terms option (under which the TC operates) of
http://www.oasis-open.org/who/intellectualproperty.php 

 

I appreciate your technical discussion, but please don't drop the IPR FUD
bomb without substantiation or explanation. Thanks.

 

-Gabe

 

  _  

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Hallam-Baker, Phillip
Sent: Thursday, January 03, 2008 3:03 PM
To: Peter Davis
Cc: OpenID specs list
Subject: Re: OpenID Email Discovery

 

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%
http://example.org/openid?joe%25 
 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%
http://example.org/openid?joe%25 
 40example.com' and use it like a regular OpenID identifier. 
 'example.org' will reply with 

RE: OpenID 2.0 finalization progress

2007-10-22 Thread Gabe Wachob
Dick is right here regarding the certainty that an IPR policy provides with
respect to patent. 

And IPR policy can never ensure that everyone in the world will refrain from
making patent claims. With regards to patent, an IPR policy and procedure
can only really affect those who choose to be subject to it, either
passively by participating in a standards process, or actively by issuing a
license or non-assert. 

So Dick is right that it's not 100% protection - but it does at least
demonstrate that those directly involved are not attempting to induce
implementations which are covered by patent claims for which patent holders
intend to demand royalties or impose other unacceptable restrictions on use.

  -Gabe

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
 Of Dick Hardt
 Sent: Monday, October 22, 2007 2:44 AM
 To: [EMAIL PROTECTED]
 Cc: specs@openid.net
 Subject: Re: OpenID 2.0 finalization progress
 
 
 On 19-Oct-07, at 10:20 PM, David Recordon wrote:
 
  Completely agreed with Johannes.  We are very close with the IPR
  policy/process being in place and assuming all the contributors agree
  to it, 2.0 can be declared final within 30 days of October 30th as
  that is the end of the public review period for the policy.  2.0 is
  really important and has a wide range of contributors, we've all put
  a lot of effort into this, lets make sure we do this right.
 
 Doing it right would have been to have had a process in place over a
 year ago. A little late to be doing it right now. Now we are having
 to clean up the mess!
 
 
  To Kevin's question, the IPR policy does not require a patent search,
  which as he points out could be a lengthy process.  Rather it
  requires that all contributors to the specification make a non-
  assertion statement to ensure that the spec truly is free and not
  encumbered by any patents.
 
 Just because the contributors all make non-assertion statements does
 not make the spec unencumbered. Non-contributors could have patents
 that are asserted.
 
 While having an IPR policy in place will, provide more certainty
 around the IPR, it will NOT ensure the spec is free.
 
 
  I spoke with Brad Fitzpatrick (cc'd)
  tonight about this and he too agrees that 2.0 should not be declared
  final until it has gone through the IPR review cycle to fully ensure
  that it is clear from any IPR encumbrances in regards to the
  contributors.
 
 You forgot to not cc Brad, and I'd prefer to hear from Brad himself
 then have you channel him.
 
 -- Dick
 ___
 specs mailing list
 specs@openid.net
 http://openid.net/mailman/listinfo/specs

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


RE: OpenID 2.0 finalization progress

2007-10-22 Thread Gabe Wachob


 -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
 Of Kevin Turner
 Sent: Monday, October 22, 2007 1:34 PM
 To: specs
 Subject: Re: OpenID 2.0 finalization progress
 
 On Fri, 2007-10-19 at 16:12 -0700, Johannes Ernst wrote:
  [...] and after they had produced a spec, Rambus said but we have
  some patents. This lead to at least one lawsuit I believe.
 
  I have heard wildly diverging assessments on whether or not this
  could happen here.
 
 Ok, I'm looking for the devil's advocate here, so let's assume the
 worst.  Say we call the spec final now, and then sometime in the next
 forty days, a problem like that comes up.  What are the consequences of
 that?  Specifically, do any of the solutions to that hypothetical
 problem involve changing the spec?  In what way?

Typically, the community would choose to remove or change the part of the
spec which ostensibly infringed upon claims raised by a patentholder. This
could be major or it could be minor. Can't tell until someone raises a
patent claim. 

 The way I understand it, right now one of two things happens:
 
 1) Things go more-or-less smoothly now.  The IPR policy may get tinkered
 with a little bit during the review period but this does not influence
 the technical specification.
 
 2) The sky falls and we decide that there is no IPR policy that can
 possibly cover the current specification, so we must change the
 specification.  Given our track record at publishing new drafts, this
 means that we wouldn't be final until _at least_ Q1 2008, if not Q2.

The third possibility is the real concern (that Johannes is referring to):

3) the community calls the spec final and a contributor raises a potential
patent infringement issue, and since the community has already implemented
and deployed 2.0, the patent owner has more leverage because the costs of
engineering around the claims in the patent have gone way up because of
already-deployed software. 

I'm not saying #3 is likely - but that's the scenario we are trying to
prevent. 

-Gabe


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


RE: OpenID 2.0 finalization progress

2007-10-22 Thread Gabe Wachob
I think that's exactly right, though it's really easy to have blind spots
when it comes to figuring out the permutations of how one can game group
behavior... so I won't guarantee anything else could happen (I've learned
that much from law school ;)

As I said, I *believe* the all the actors involved wish to work in the
community's best interest - though my belief in the goodness of humanity
doesn't really carry any legal meaning!!!

-Gabe

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Josh
 Hoyt
 Sent: Monday, October 22, 2007 3:29 PM
 To: Gabe Wachob
 Cc: Kevin Turner; specs
 Subject: Re: OpenID 2.0 finalization progress
 
 On 10/22/07, Gabe Wachob [EMAIL PROTECTED] wrote:
  3) the community calls the spec final and a contributor raises a
 potential
  patent infringement issue, and since the community has already
 implemented
  and deployed 2.0, the patent owner has more leverage because the costs
 of
  engineering around the claims in the patent have gone way up because
 of
  already-deployed software.
 
 In order for this to be a concern, there needs to be a party who
 currently:
  1. has a patent that the spec infringes upon
  -- and --
  2. intends to claim infringement it if the spec is released without
 an IPR agreement in place
  -- and --
  3. would be party to the IPR agreement
 
 Did I get this right?
 
 Josh

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


RE: OpenID 2.0 finalization progress

2007-10-19 Thread Gabe Wachob
I've already suggested that to the OAuth community and they are heartily
taking up that suggestion... 

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
 Of Pat Patterson
 Sent: Friday, October 19, 2007 4:36 PM
 To: Johannes Ernst
 Cc: specs@openid.net
 Subject: Re: OpenID 2.0 finalization progress
 
 +1 FWIW
 
 Interested parties, feel free to use the Sun OpenID NAC as a model -
 http://www.sun.com/software/standards/persistent/openid/nac.xml
 
 Cheers,
 
 Pat
 
 On Oct 19, 2007, at 4:12 PM, Johannes Ernst wrote:
 
  Some years ago, if I recall correctly, Rambus participated in an open
  industry process (or so the other participants thought) to define
  certain memory communications protocols, and after they had produced
  a spec, Rambus said but we have some patents. This lead to at least
  one lawsuit I believe.
 
  I have heard wildly diverging assessments on whether or not this
  could happen here. The way to move forward is to put the IPR policy
  in place prior to declaring any new specs final; fortunately we are
  very close on the IPR policy.
 
  I strongly suggest that whoever feels the urgency to get a 2.0 spec
  declared final to help out driving the IPR process to a close. That's
  on the critical path, and that's where all energies should be
  directed.
 
  On Oct 19, 2007, at 12:23, Kevin Turner wrote:
 
  On Fri, 2007-10-19 at 10:02 -0700, Paul C. Bryan wrote:
  On Thu, 2007-10-18 at 19:13 -0700, Dick Hardt wrote:
 
  I don't see why the two processes need to be any more dependant on
  each other then they are already.
 
  With all due respect, why take the risk that there are intellectual
  property issues after the specification is finalized?
 
  I'll let my ignorance show here: How will any potential IPR issues
  affect the final specification?  I recognize that many parties
  require
  the IPR documentation before moving forward with their adoption of
  OpenID.  However, there are many parties who do _not_ feel that need,
  and I do not understand what the downside is to calling the
  specification final now.  Are we waiting on the results of a patent
  search which might necessitate re-working parts of the protocol?
  What
  exactly are the consequences, worst case, in calling the
  specification
  final before the IPR is sealed?
 
 
 
  ___
  specs mailing list
  specs@openid.net
  http://openid.net/mailman/listinfo/specs
 
  ___
  specs mailing list
  specs@openid.net
  http://openid.net/mailman/listinfo/specs
 
 - - - - -
 Pat Patterson
 Federation Architect, Sun Microsystems, Inc.
 [EMAIL PROTECTED] - http://blogs.sun.com/superpat
 - - - - -
 Join OpenSSO today! http://opensso.dev.java.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: Using dots in HTTP request parameters

2007-09-14 Thread Gabe Wachob
Not sure it matters in the O* environments, but using _ in http links has
traditionally been frowned upon because it when rendered as underlined text
(as an HTML link), the underscores disappeared and made it look like a space
was present in the link. 


-Gabe

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
 Of Jonathan Daugherty
 Sent: Friday, September 14, 2007 11:05 AM
 To: Eran Hammer-Lahav
 Cc: specs@openid.net
 Subject: Re: Using dots in HTTP request parameters
 
 # OAuth is designed to work with old browsers, cell phones, webtv,
 # etc. Is there any reason not to use dot in parameters name? Are
 # there any known compatibility or support issues (compared to using
 # underscores)?
 
 PHP has an especially pathological behavior of converting all dots in
 query parameter names to underscores, so if you do go this route
 you'll need code[1] to fix it.  Otherwise I think it's a fine idea. :)
 
 [1] Auth_OpenID::getQuery()
 http://openidenabled.com/files/php-openid/repos/2.x.x/Auth/OpenID.php
 
 --
   Jonathan Daugherty
   JanRain, Inc.
   irc.freenode.net: cygnus in #openid
   cygnus.myopenid.com
 ___
 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: RFC: Final outstanding issues with the OpenID 2.0Authenticationspecification

2007-05-17 Thread Gabe Wachob
BTW, we (the XRI TC cochairs) finally (!) came to agreement at IIW to
publish the current draft of the XRI Res spec as a citeable committee spec
so the issue about XRI specs being in draft form and unciteable goes away.
That is, we'll hold a TC vote on what has already been implemented by the
openid community and call it XRI resolution 2.0 (which has been relatively
stable, but not final, for a long time already). XRI Syntax 2.0 has been a
committee spec for a long time now and has not changed. The agreement was,
essentially, to output res 2.0 wd 11 (or thereabouts) as a committee spec
rather than wait for further work on XRI.  

We've not formally presented this to the TC, but I am almost certain the TC
will agree to this. 

It is my expectation that we'll complete this in roughly the same timeframe
as the other work being completed in OpenID 2.0 (that is, on the order of
weeks). 

-Gabe

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
 Of Josh Hoyt
 Sent: Thursday, May 17, 2007 1:40 PM
 To: Dmitry Shechtman
 Cc: OpenID specs list
 Subject: Re: RFC: Final outstanding issues with the OpenID
 2.0Authenticationspecification
 
 On 5/17/07, Dmitry Shechtman [EMAIL PROTECTED] wrote:
  aside from XRI and Yadis? XRI alone is twice as complex as OpenID 1.1!
 
  There has been a simplification suggestion floating around since long
 ago:
  resolve i-names via http[s]://xri.net/.
 
 -1. If XRI is to be included, it should be done the way that it's
 intended. One possible solution that would address this problem as
 well as the unfinished XRI specification is to split out Yadis and XRI
 discovery out from the OpenID Authentication spec and into separate
 documents. That way, they could wait until the XRI specs are done and
 the OpenID spec will be shorter and easier to understand.
 
 Josh
 ___
 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: Java RP

2007-04-11 Thread Gabe Wachob
Hans-
I didn't see XRI support in joid - was I mistaken? 

-Gabe

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
 Of Granqvist, Hans
 Sent: Wednesday, April 11, 2007 9:31 AM
 To: Dick Hardt; McGovern, James F ((HTSC, IT))
 Cc: specs@openid.net
 Subject: RE: Java RP
 
 Or this library (also ASF 2.0) for creating both OP and RP,
 which follows a slightly different API approach:
 
  http://code.google.com/p/joid
 
 (If you're coming to JavaOne in May, there will be a
 presentation on it.)
 
 -Hans
 
 
  -Original Message-
  From: [EMAIL PROTECTED]
  [mailto:[EMAIL PROTECTED] On Behalf Of Dick Hardt
  Sent: Wednesday, April 11, 2007 9:15 AM
  To: McGovern, James F ((HTSC, IT))
  Cc: specs@openid.net
  Subject: Re: Java RP
 
  The OpenID4Java library is licensed under Apache 2.0 -- a
  very commercial friendly license
 
  source development here:
  http://code.google.com/p/openid4java/source
 
  package here:
  http://code.sxip.com/openid4java/
 
  -- Dick
 
  On 11-Apr-07, at 6:37 AM, McGovern, James F ((HTSC, IT)) wrote:
 
   I have been thinking that the best contribution I could
  make to OpenID
   would be the first enterprise that deploys OpenID into production.
   OpenID needs more press than it is receiving and by showing that a
   large Fortune enterprise is using would be a big win. I do however
   have one constraint in that the absolute fastest way of
  accomplishing
   deployment would be for me to identify a 100% unrestricted
  open source
   Java RP code base that I could incorporate.
  
   The notion of going through any form of procurement would
  not allow me
   to accomplish this goal. Is anyone aware of the existence of a 100%
   unrestricted open source Java RP code base?
  
  
  
  **
  
   ***
   This communication, including attachments, is
   for the exclusive use of addressee and may contain proprietary,
   confidential and/or privileged information.  If you are not the
   intended
   recipient, any use, copying, disclosure, dissemination or
   distribution is
   strictly prohibited.  If you are not the intended
  recipient, please
   notify
   the sender immediately by return e-mail, delete this
  communication and
   destroy all copies.
  
  **
  
   ***
  
   ___
   specs mailing list
   specs@openid.net
   http://openid.net/mailman/listinfo/specs
  
  
 
  ___
  specs mailing list
  specs@openid.net
  http://openid.net/mailman/listinfo/specs
 
 ___
 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: Promoting OpenID

2007-04-03 Thread Gabe Wachob
More likely that the people promoting OpenID to large organizations are
vendors and don't particularly want to tell their competitors what they are
doing. 

Now, imagine if there were like-minded vendors getting together to form some
sort of marketing organization to promote OpenID to a variety of audiences,
including large enterprises... ;-)

-Gabe

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
 Of Recordon, David
 Sent: Tuesday, April 03, 2007 12:18 PM
 To: McGovern, James F (HTSC, IT); specs@openid.net
 Subject: RE: Promoting OpenID
 
 People might be, though nothing real formal that I personally know of.
 You volunteering? :P
 
 --David
 
 -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
 Behalf Of McGovern, James F (HTSC, IT)
 Sent: Monday, April 02, 2007 8:15 AM
 To: specs@openid.net
 Subject: Promoting OpenID
 
 As an end-user to user-centric approaches, I have noticed an interesting
 pattern. Microsoft does a wonderful job of selling Cardspace as a
 solution to others who develop in Microsoft languages. Likewise, there
 are tons of vendors that can offer solutions for large enterprises to
 purchase but no one is promoting user-centric approaches to the vendors
 us large enterprises do business with in terms of getting them to
 embrace user-centric approaches within their own code base. Sure, we can
 as consumers raise awareness, but I would like to understand thoughts on
 other than procurement, how could we make this more pervasive?
 
 Is anyone here working with vendors in the ERP, CRM, ECM, BPM or VRM
 spaces such that user-centric identity is built into their product?
 
 
 
 *
 This communication, including attachments, is for the exclusive use of
 addressee and may contain proprietary, confidential and/or privileged
 information.  If you are not the intended recipient, any use, copying,
 disclosure, dissemination or distribution is strictly prohibited.  If
 you are not the intended recipient, please notify the sender immediately
 by return e-mail, delete this communication and destroy all copies.
 
 *
 
 ___
 specs mailing list
 specs@openid.net
 http://openid.net/mailman/listinfo/specs
 ___
 specs mailing list
 specs@openid.net
 http://openid.net/mailman/listinfo/specs

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


RE: Features for Future Versions

2007-04-02 Thread Gabe Wachob
p style=tone:caution
Before we get into the discussions on this list (and hopefully elsewhere),
it would be great if you (and anyone else contributing) could make a clear
IPR statement about your intent with this new functionality. If you wanted
to use Microsoft's Open Specification Promise as a template, that would be
great. We don't have formal policy about IPR moving forward (and how such a
policy would be enforced...), but the more intentions are made clear earlier
on, he better it is for everyone involved. 
/p

p style=tone:apology
David Recordon and I have been pulled in 14 different directions - one of
the things we are tasked with is cleaning up the IPR around OpenID. Such a
task would have been made simpler if everyone had stated up front that their
contributions were not subject to IPR claims (or that if they were, they
would be licensed for use with OpenID, etc). Of course, without a more
formal process and IPR policy in place, such commitments to IPR openness are
not very likely to be given forth ad hoc. So this isn't a criticism, its
just a result of the way things have happened. 
/p
-Gabe

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
 Of Drummond Reed
 Sent: Monday, April 02, 2007 11:26 AM
 To: 'Dick Hardt'; 'McGovern, James F ((HTSC, IT))'
 Cc: specs@openid.net
 Subject: RE: Features for Future Versions
 
 James,
 
 I agree with Dick's feedback. I don't believe OpenID, as an overall
 Internet
 identity framework, is subject to either limitation you asked about. But
 we
 must work our way up into each of those areas of functionality.
 
 The more you can tell us about specific functions and use cases you'd like
 to see supported, the better we can appraise what it will take to get
 there.
 
 =Drummond
 
 -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
 Of Dick Hardt
 Sent: Monday, April 02, 2007 8:20 AM
 To: McGovern, James F ((HTSC, IT))
 Cc: specs@openid.net
 Subject: Re: Features for Future Versions
 
 
 On 2-Apr-07, at 8:09 AM, McGovern, James F ((HTSC, IT)) wrote:
 
  I originally joined this list with the hopes of injecting support
  for relationships, authorization and attestation into the
  specification but have been somewhat disappointed. I do have the
  following questions?
 
  1. Will OpenID avoid incorporating features where identity
  selectors such as Cardspace don't support the functionality?
 
  2. Will OpenID always constrain itself to areas where traditional
  PKI vendors have played (authentication) and avoid areas where PKI
  can't tread (authorization)?
 
 Hi James
 
 Authentication and authorization are somewhat overloaded words and
 different people mean different things by them. I recall you sending
 out a link to a set of requirements you had helped create. The
 dynamics of this mailing list tend to support concise use case
 discussion rather delve into large documents. A concise use case of
 what you mean by Authorization may prove useful to guide the
 discussion and work.
 
 -- Dick
 
 ___
 specs mailing list
 specs@openid.net
 http://openid.net/mailman/listinfo/specs
 
 ___
 specs mailing list
 specs@openid.net
 http://openid.net/mailman/listinfo/specs

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


Proposal for Modularizing Auth 2.0 Discovery

2007-02-28 Thread Gabe Wachob

I'm trying to follow this while at ETEL - not all of us can keep up with
this list on a minute-by-minute basis ;-)

Here's a proposal for a modular OpenID Discovery Spec, which I'll volunteer
to help edit since I am responsible for the XRI resolution spec and the XRDS
document format.

Basically, the Discovery Spec would specify that for any identifier scheme
to work with OpenID, it MUST define a way of being constructed into an HTTP
URI and then returning a XRDS with an HTTP GET on that HTTP URI. If there
are other ways of resolving it, then implementations MAY use those other
methods of resolution (native resolution, if you will). In essence, this
is a requirement for HTTP gateway(s) to whatever resolution infrastructure
exists today. 

This is exactly what we do with XRIs -- http://xri{.domain*}/xri?some
stuff is the form of the HTTP URL and it gets back the XRDS you need.
Implementations can also do native XRI resolution (which is a series of HTTP
requests) - but they are not required to (there will be advantages to doing
this in the future, but implementations won't be required to do native
resolution). 

Of course, it's pretty much a null-op for HTTP URIs, except that there's a
fallback for doing HTML-based discovery. 

---

I'd also support some way of making the specs for XRDS easier to comprehend
for non-XRI developers. In particular, a profile for XRDS which says which
elements are important for the common functions of OpenID. 

-Gabe


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


CROSS POSTING :-(

2007-01-22 Thread Gabe Wachob
This is getting a little insane - many of us are subscribed to the four
lists that this thread has been posted to. 

One person has suggested that we actually consolidate the separate lists
given the overlap in membership and topics (at least the openid lists). The
other option is to be more disciplined about posting.

In any case, having most threads cross posted to 4 lists seems insane and
unworkable to me.

What's the mood on consolidating the lists? I'd rather we just be careful
about cross posting and keep the separate lists, but that may be too much to
ask. 

-Gabe

P.S. Yes, I realize this is cross posted ;-)

 -Original Message-
 From: Marcin JagodziƄski [mailto:[EMAIL PROTECTED]
 Sent: Monday, January 22, 2007 10:47 AM
 To: Ben Laurie
 Cc: Josh Hoyt; [EMAIL PROTECTED]; specs@openid.net; openid-general;
 heraldry-dev@incubator.apache.org
 Subject: Re: [security] [OpenID] Announcing OpenID Authentication 2.0 -
 Implementor's Draft 11
 
 2007/1/22, Ben Laurie [EMAIL PROTECTED]:
  Actually, it appears to allow the RP to tell the OP what kind of
  authentication was used, which is backwards.
 
  It also seems to be rather lacking in meat. Still, a step in the right
  direction.
 
 
 I asked this question some time ago: is there any possibility for RP
 to ask OP to use some authentication method? Or another scenario: how
 can user select one of OP's for this particular authentication from
 his Yadis file.
 
 regards,
 
 Marcin

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


RE: [OpenID] OpenID IPR Policy Draft

2006-12-21 Thread Gabe Wachob
Yes, you missed #4.

I think #3 is still a debatable point. It causes *problems* for open source,
but those problems are dealt with today -- at least from what I see. I agree
with Ben Laurie that it would be much better if the automatic creation of a
license could be made to happen, but there are some practicalities legally
and procedurally (when does a license come into being? Does this mean that
everyone with IPR that needs to be licensed has to agree to the exact same
license?) that could make imposing this difficult. 

This is definitely one of the first topics that we can discuss with
appropriate legal counsel if we choose to go that direction before we take
OpenID to a standards organization that has already solved these issues (or
not, according to Ben). 
  

-Gabe

 -Original Message-
 From: Recordon, David [mailto:[EMAIL PROTECTED]
 Sent: Thursday, December 21, 2006 11:27 AM
 To: [EMAIL PROTECTED]; Gabe Wachob
 Cc: specs@openid.net
 Subject: RE: [OpenID] OpenID IPR Policy Draft
 
 So just circling back on this, summarizing the key points I saw from the
 discussion.
 
 1) We can't directly take the IPR Policy from a SDO (such as the W3C)
 and use it verbatim.  Those policies are tied to the specific SDO's
 policies and procedures which we'd also have to adopt in order to be
 useful.
 2) The trigger for disclosure has to be active, not passive.
 3) Just requiring issuance of a license is not strong enough to support
 Open Source implementations.  Rather needs to be worded along the lines
 of a unilateral license or covenant of non-assertion (etc) that does
 not require affirmative action on the part of the licensee.
 Microsoft's Open Specification Promise is viewed by members of the IETF
 community as the clearest expression of this.
 5) The OpenID community could theoretically patent its own work to
 prevent someone else from trying to claim the invention.
 
 I miss anything?
 
 --David
 
 -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
 Behalf Of Recordon, David
 Sent: Wednesday, December 06, 2006 2:43 PM
 To: [EMAIL PROTECTED]
 Cc: specs@openid.net
 Subject: [OpenID] OpenID IPR Policy Draft
 
 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
 ___
 general mailing list
 [EMAIL PROTECTED]
 http://openid.net/mailman/listinfo/general

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


RE: [OpenID] Opened IPR Policy Draft

2006-12-12 Thread Gabe Wachob
Well said Phill. 

We'd like to take an off-the-shelf policy that is comes with an
off-the-shelf process (the two are very intertwined) that produces
specifications that can be taken to more established SDOs. Once this thing
exists, this IPR discussion can be very much quicker.

As you've noted in earlier emails, the landscape is still changing, and even
the SDOs are just now getting their arms around the optimal IPR policies for
themselves. But because these IPR policies are based on concepts like
membership and termination of membership and votes to approve
contributions, we can't simply import them wholesale, unless we adopt those
process concepts as well. 

I'd like to have the one IPR policy/process to rule them all (at least for
open community-based standards like OpenID). We're not there yet. Maybe
we're making steps in the right direction, though.

-Gabe



 -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
 Behalf Of Hallam-Baker, Phillip
 Sent: Tuesday, December 12, 2006 11:12 AM
 To: David Nicol; James A. Donald
 Cc: Martin Atkins; Gavin Baumanis; specs@openid.net; [EMAIL PROTECTED]
 Subject: Re: [OpenID] Opened IPR Policy Draft
 
 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
 
 
 ___
 general mailing list
 [EMAIL PROTECTED]
 http://openid.net/mailman/listinfo/general

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


RE: [OpenID] OpenID IPR Policy Draft

2006-12-08 Thread Gabe Wachob
James-

Yes, you're correct. We can't control people who aren't covered by the
policy and they can often be the ones who (legitimately or not) have IPR
claims that can disrupt our work. 

We *can* however, take care of the cases where someone joins the group and
actively promotes a technology decision based not on technical merit, but
rather based on a desire to generate licensing revenue (or other market
influence) based on their patent claims. 

Unfortunately, there's risk no matter what we do - the attempt here is to
reduce the risk as much as is practical given the loose process and open
community focus we have. 

-Gabe

 -Original Message-
 From: James A. Donald [mailto:[EMAIL PROTECTED]
 Sent: Friday, December 08, 2006 9:31 PM
 To: Gabe Wachob
 Cc: 'Martin Atkins'; [EMAIL PROTECTED]; specs@openid.net
 Subject: Re: [OpenID] OpenID IPR Policy Draft
 
 Gabe Wachob wrote:
   Actually, the language was changed from post to a
   list, not subscribe to a list for this very reason.
 
 It appears to me that your intent is, or should be, to
 protect against patent trolls, who are likely to
 retroactively patent the OpenID standard now that it is
 being widely adopted.
 
 In the US, you can file a patent in which you *claim*
 you invented stuff one year prior to the patent
 application.
 
 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
 patent application claiming to have invented the
 technology on 2007, december 6.
 
 They keep the patent under water for a couple of years,
 preventing it from being published, until evil unpopular
 giant megacorp, say intel, has been using the technology
 for some time.  They then surface the patent.  Should
 intel fail to settle, they have inventor tell the jury
 he is being oppressed by evil giant megacorp.  Jury
 awards the patent troll a zillion dollars, and cabillion
 on top of that.
 
 Unfortunately, your proposed measure is of limited
 effectiveness, since the our friend the highly jury
 sympathetic inventor is probably not signed up on this
 list, his expertise being primarily in being loved by
 juries, rather than computer technology.
 
 Indeed, no measures whatsoever are likely to be very
 effective.  The patent office wants people to take out
 more patents, just as Ford wants people to buy more
 Fords.  The judiciary similarly wants more human
 activity to be subject to patents, just as they want
 more laws, and those laws of broader scope, hence the
 steady shrinkage of any portion of the constitution that
 begins congress shall make no law ...

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


RE: OpenID IPR Policy Draft

2006-12-07 Thread Gabe Wachob
The reason is easy - each of these organizations has a different process and
the IPR is intimately tied to process (for example, when certain disclosure
and licensing agreements come into force). 

 

In addition, some bodies offer a broader spectrum of levels of IPR
encumberance for the specs produced in each body. 

 

They actually don't differ much beyond this, however, and the spirit of the
respective IPR policies are converging.

 

-Gabe

 

  _  

From: Hallam-Baker, Phillip [mailto:[EMAIL PROTECTED] 
Sent: Thursday, December 07, 2006 10:20 AM
To: Gabe Wachob; Brett McDowell; Recordon, David
Cc: specs@openid.net; [EMAIL PROTECTED]
Subject: RE: OpenID IPR Policy Draft

 

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: OpenID IPR Policy Draft

2006-12-07 Thread Gabe Wachob
Actually, the language was changed from post to a list, not subscribe to
a list for this very reason. 

Our intent was to come up with another simple trigger that didn't involve a
lot of process (and was clear and not subject to much interpretation) and
decided that this was a reasonable first cut (the act of posting to the
list). What other simple trigger would you suggest? How do you define
contribution? Who defines contribution? This is fuzzy line here - we were
trying to enclose the largest scope of contributions to minimize questions
later on whether or not an idea was contributed or not (e.g. a
patent-covered claim can be incorporated in a specification whether or not a
patent owner actually contributes *text*). 

This stuff is rather complicated and since we are not doing it within the
confines of a traditional standards body, we either have to take the time to
do a formal IPR policy which implies more formal process (introducing
friction to wider community participation), OR we have to have a IPR policy
that acknowledges the loose procedure we are using and recognizes the risk
of this approach with respect to IPR disclosure and licensing. There's no
free lunch here. 

The one thing I think we really should avoid is recreating a more formal
standards body from scratch - its hard work and these bodies already exist.
If this community really believes that we need the more formal process and
IPR policy, then we should consider taking this effort to a standards body
like OASIS *now* rather than later. 

I think a number of us working on this hoped that we could get this work to
an implementable state sooner than it would be practical to move to a formal
standards body. The current work on IPR policy is a stopgap measure until
such a time that we decide to take the work to a more formal standards body.
 

-Gabe



 -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
 Of Martin Atkins
 Sent: Thursday, December 07, 2006 10:54 AM
 To: [EMAIL PROTECTED]; specs@openid.net
 Subject: Re: OpenID IPR Policy Draft
 
 Recordon, David wrote:
 
  http://openid.net/wiki/index.php/IPR_Policy
 
 
 Is it really possible to use mailing list subscription as a trigger for
 a contract like this? The whole idea scares me a little bit, to be honest.
 
 It seems more sensible to me to put these restrictions on actual
 *contributions*: require that any proposal or concrete
 specification/implementation offered via the mailing lists or other
 official channels to come with patent disclosure, and only *then* are
 any undisclosed patents assumed to constitute a royalty-free, perpetual
 licence.
 
 As it is currently written, I think lots of companies that retain
 software patents of any kind - or even ones that don't but may wish to
 in the future - would be put off contributing due to the risk that their
 patents may be implicitly licenced to everyone.
 
 I'm not a lawyer, of course. However, not everyone who could potentially
 be affected by this is a lawyer either, so putting in stuff that
 potentially scares non-lawyers like myself is probably a bad idea.
 
 
 ___
 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] OpenID IPR Policy Draft

2006-12-07 Thread Gabe Wachob
Ben-
I'm not sure what you are suggesting is the problem - is this just a
matter of timing? That is, could we remedy your issue by saying that you
have to issue the license before a certain event? This language is pretty
common - I'm not sure what else a policy could say? 

Are you suggesting that there is some sort of implied license or
estoppel that comes into creation by virtue of the policy? I'm not aware of
any IPR policy in standards bodies that works that way - and I'm not sure
its really effective from a legal point of view. 

As an alternative, when we say issue a license, perhaps we should
be saying a unilateral license or covenant of non-assertion (etc) that does
not require affirmative action on the part of the licensee (needs to be
worded right - but does that capture your intent?) I'd note that the w3c and
oasis (rf on limited terms) policies do *not* require patent licensors to
issue these sort of super-low-friction licenses (though I've personally
pushed for it within OASIS). 

-Gabe

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
 Behalf Of Ben Laurie
 Sent: Thursday, December 07, 2006 8:31 AM
 To: Recordon, David
 Cc: specs@openid.net; [EMAIL PROTECTED]
 Subject: Re: [OpenID] OpenID IPR Policy Draft
 
 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
 
 A problem with saying you MUST offer ... a royalty free license is
 that in order to be open-source-friendly the licence has to be
 automatic - otherwise potentially each user of the s/w has to jump
 through hoops to get the licence.
 
 
  Thanks,
  --David
  ___
  general mailing list
  [EMAIL PROTECTED]
  http://openid.net/mailman/listinfo/general
 
 ___
 general mailing list
 [EMAIL PROTECTED]
 http://openid.net/mailman/listinfo/general

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


RE: Delegation discussion summary

2006-10-12 Thread Gabe Wachob
*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 IdP lock-in)
 
 Each portable identifiers has an IdP-specific identifier tied to it.
 This identifier allows the IdP to know what credentials to require
 before issuing an authentication response even though the IdP does not
 control the portable identifier.
 
 Throughout this discussion, I will assume that there is a portable
 identifier called http://my.portable.url/; that uses an IdP-specific
 identifier called http://my.idp.specific.url/;.
 
 
 Current implementation
 ==
 
 OpenID 1 [2]_ calls portable identifier support delegation. In this
 implementation, the IdP-specific identifier is the only identifier that