RE: Separation of Discovery from AuthN (was Proposal to form Discovery Working Group)

2009-01-05 Thread Drummond Reed
Agreed that it makes sense to split it out when the underlying work (XRD
1.0) is ready.

 

=Drummond 

 

  _  

From: David Recordon [mailto:drecor...@sixapart.com] 
Sent: Sunday, January 04, 2009 11:24 PM
To: Drummond Reed
Cc: sappe...@gmail.com; 'Nat Sakimura'; 'John Bradley'; specs@openid.net
Subject: Re: Separation of Discovery from AuthN (was Proposal to form
Discovery Working Group)

 

I'd advocate for waiting until all of the discovery work occurring in OASIS,
IETF, and W3C shakes out before we make changes to how OpenID discovery
works.  I'd much rather make this sort of change once rather than twice.

 

--David

 

On Jan 4, 2009, at 11:14 PM, Drummond Reed wrote:





I'm just catching up on holiday mail and wanted to add another +1 to
separation of Discovery from AuthN. The sooner the better.

 

=Drummond

 

  _  

From: specs-boun...@openid.net [mailto:specs-boun...@openid.net] On Behalf
Of David Fuelling
Sent: Friday, December 26, 2008 8:47 AM
To: Nat Sakimura
Cc: John Bradley; specs@openid.net
Subject: Re: Proposal to form Discovery Working Group

 

On Thu, Dec 25, 2008 at 10:56 AM, Nat Sakimura n-sakim...@nri.co.jp wrote:

2. Separation of OP into Discovery Service and Authentication Service.
 In the current terminology, OP spans both Discovery Service and
Authentication Service.
 We should be explicit about it.


+1.  I would like to see discovery services separated from OP services too.
 



John Bradley wrote:
 Breno,

 I agree.  I recommended separating discovery into a separate doc for
 2.1.

 There didn't seem to be support for the idea at the time,  perhaps
 circumstances have changed and the idea will be accepted now.

 Regards
 John Bradley
 =jbradley

 

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

 

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


Separation of Discovery from AuthN (was Proposal to form Discovery Working Group)

2009-01-04 Thread Drummond Reed
I'm just catching up on holiday mail and wanted to add another +1 to
separation of Discovery from AuthN. The sooner the better.

 

=Drummond 

 

  _  

From: specs-boun...@openid.net [mailto:specs-boun...@openid.net] On Behalf
Of David Fuelling
Sent: Friday, December 26, 2008 8:47 AM
To: Nat Sakimura
Cc: John Bradley; specs@openid.net
Subject: Re: Proposal to form Discovery Working Group

 

On Thu, Dec 25, 2008 at 10:56 AM, Nat Sakimura n-sakim...@nri.co.jp wrote:

2. Separation of OP into Discovery Service and Authentication Service.
 In the current terminology, OP spans both Discovery Service and
Authentication Service.
 We should be explicit about it.


+1.  I would like to see discovery services separated from OP services too.
 



John Bradley wrote:
 Breno,

 I agree.  I recommended separating discovery into a separate doc for
 2.1.

 There didn't seem to be support for the idea at the time,  perhaps
 circumstances have changed and the idea will be accepted now.

 Regards
 John Bradley
 =jbradley

 

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


RE: Proposal to create the TX working group

2008-11-08 Thread Drummond Reed
*   Conformance requirements for other data transfer protocol bindings

*   Security, threats and Risk analysis

*   Perform Security Risk analysis and profiles for best practice

 Out of scope

*   Term negotiation: Actual negotiation of the terms of a contract
should be dealt with out-of-band or by other specifications. 
*   General purpose data type identifiers: this should be determined on
a per-community bases using other specifications such as OpenID Attribute
Exchange.
*   Assurance programs or other identity governance frameworks.
*   It is the intent that this specification be usable by any trust
community, whether it uses conventional PKI hierarchies, peer-to-peer trust
mechanisms, reputation systems, or other forms of trust assurance. The
specification of any particular trust root, trust hierarchy, or trust policy
is explicitly out of scope.


 (iv)  Proposed List of Specifications:  TX 1.0, spec completion expected in
January 2009.

 (v)  Anticipated audience or users of the work:  Implementers of OpenID
Providers and Relying Parties, especially those who require security and
accountability features to exchange sensitive customer information (e.g.
personally identifiable information and credit card numbers) responsibly
among trusted parties.

 (vi)  Language in which the WG will conduct business:  English.

 (vii)  Method of work:  E-mail discussions on the working group mailing
list, working group conference calls, and possibly face-to-face meetings at
conferences.

 (viii)  Basis for determining when the work of the WG is completed:  Draft
1 will be evaluated on the basis of whether they increase or decrease
consensus within the working group.  The work will be completed once it is
apparent that maximal consensus on the draft has been achieved, consistent
with the purpose and scope.

(b)  Background Information.

 (i)  Related work being done by other WGs or organizations: 

*   LIberty Alliance Identity Governance Framework (IGF) 1.0
http://www.projectliberty.org/liberty/content/download/4329/28939/file/libe
rty-igf-draft-1.0-2008-06-21.zip  Draft 
*   XML Advanced Electronic http://www.w3.org/TR/XAdES/  Signatures
(XAdES)

  
 (ii)  Proposers:

   Drummond Reed, [EMAIL PROTECTED], Cordance/Parity/OASIS (U.S.A)
   Henrik Biering, [EMAIL PROTECTED], Netamia (Denmark)
   Hideki Nara, [EMAIL PROTECTED], Tact Communications (Japan)
   John Bradeley, [EMAIL PROTECTED], OASIS IDTrust Member Section (Canada)
   Mike Graves, [EMAIL PROTECTED], JanRain, Inc. (U.S.A.)
   Nat Sakimura, [EMAIL PROTECTED], Nomura Research Institute,
Ltd.(Japan)
   Robert Ott, [EMAIL PROTECTED], Clavid (Switzerland)
   Tatsuki Sakushima, [EMAIL PROTECTED], NRI America, Ltd. (U.S.A.)
   Toru Yamaguchi, [EMAIL PROTECTED], Cyboze Lab (Japan)


   Editors:

   Nat Sakimura, [EMAIL PROTECTED], Nomura Research Institute, Ltd.

 (iii)  Anticipated Contributions:  
(1) Sakimura, N., et. al
http://svn.sourceforge.jp/cgi-bin/viewcvs.cgi/*checkout*/spec/openid-trust-
exchange-1_0.html?root=openidtx OpenID Trusted data eXchange Extention
Specification (draft), Oct. 2008. [TX2008]. 

 

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

 


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




-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/

 




-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/




-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/

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


RE: This is user's URI for Assertion Quality Extension

2008-09-05 Thread Drummond Reed
Shade, here's the nut of the problem: directed identity in OpenID
Authentication 2.0 means nothing more than:

The user logging in to your site is not asserting the URI they have typed
in; instead the OP will tell you the URI for the user.

Then _any_ URI then returned from the OP *is* then the user's URI. For
example, I could enter myopenid.com when logging into an RP, have the RP
discover the myopenid.com directed identity service there, and then instruct
myopenid.com to return xri://=!F83.62B1.44F.2813 as my URI (which is the XRI
i-number for my i-names =drummond and =drummond.reed).

So the RP would end up exactly the same identifier an RP would dicover if I
logged in as =drummond. 

That's the way directed identity is designed to work. It's not necessarily
about anonymity -- it's about letting the user choose their URI at the OP
rather than typing it into the RP.

So net net is I don't think there's any way to ascertain a real URI even
if there was such a thing. It can and should be the user's choice what URIs
he/she shares with what sites. If a site has a particular reason to know
that a user has shared a particular URI with another particular site, that's
different -- and the OpenID protocol could be used to prove that. But I
don't think that's what you're asking.

=Drummond 

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
 Of SitG Admin
 Sent: Friday, September 05, 2008 1:48 PM
 To: specs@openid.net
 Subject: RE: This is user's URI for Assertion Quality Extension
 
 None of them were assumed by me; I don't consider the use-case to
 rely on any of them.
 
 1) A directed identity URI creates a situation where the RP *doesn't
 know* whether it is a real URI or not. (This assumption has been
 hypothetically mitigated by an idea that occurred to me during this
 discussion, of performing discovery on the asserted URI as normal and
 looking for any OpenID headers.)
 
 2) There are other reasons for using Directed Identity (such as being
 able to give all users the same URL to use instead of asking them to
 figure out what a URL would look like with their username substituted
 for the example text), reasons that have nothing to do with privacy.
 RP's may, at their discretion, encourage use of Directed Identity
 (adoption of the feature, where offered at the site hosting user's
 URI) by treating those who *don't* use it (when available) as
 second-class citizens! Or just ignore (not even request, really) this
 information completely. Like any of the other quality assertion
 strings (biometrics, phone), it's not there because ALL the Relying
 Parties MUST use it, but because *some* of us *may* want to. Whether
 a RP discriminates and whether it's for or against is not dictated by
 this proposal.
 
 3) Do you know what the web will look like if no user ever employs
 the same URI at more than one site? The same walled gardens we have
 right now, that's what. One account per site. OpenID doesn't provide
 Identity in any meaningful way (and certainly not Open) if we don't
 see users employing at least one URI on at least two sites. Providing
 the means to detect when they're using a unique URI over the long
 term, so they can at least be educated about the implications (if not
 encouraged to practice a consistent URI), does not strike me as a bad
 thing.
 
 -Shade
 ___
 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: IDMML (was RE: Using email address as OpenID identifier)

2008-04-02 Thread Drummond Reed
Chris, I remember that well, and I agree that it makes a lot of sense. I
think when this is combined with George's concept of the other ways in which
a local identity agent can assist the use, then IDMML really starts to gain
some legs.

See also my reply to George.

=Drummond 

 -Original Message-
 From: Chris Drake [mailto:[EMAIL PROTECTED]
 Sent: Wednesday, April 02, 2008 1:30 PM
 To: Drummond Reed
 Cc: 'George Fletcher'; 'Dick Hardt'; specs@openid.net
 Subject: Re: IDMML (was RE: Using email address as OpenID identifier)
 
 Hi Drummond,
 
 I pushed hard for RP identification for 2 or 3 months back around
 October 2006.  If anyone wants to go back through the archives,
 there's a pile of other important reasons to have some way that an IdP
 and/or browser agent can identify an OpenID-enabled site.  The antique
 thread below lists a few.  My proposal too was a link tag.
 
 Kind Regards,
 Chris Drake
 
 
 Tuesday, November 7, 2006, 12:51:15 I, you wrote:
 
 CD Hi Johannes,
 
 CD I proposed a solution to the single sign out problem a month or two
 CD ago.
 
 CD In fact - a whole range of solutions have been proposed, and relative
 CD merits of all discussed already - does anyone have the free time to go
 CD back over the postings, extract all the knowledge  contributions, and
 CD document them all?
 
 CD To summarize my proposal - I was seeking a standardized OpenID RP
 CD endpoint interface into which I (as an IdP) or a software agent (eg: a
 CD browser plugin) could post user information - be this a login
 CD request, email change request, log-out request, account signup,
 CD account cancelation, or whatever.  My preferred implementation was a
 CD LINK tag placed on (and thus identifying) a login page, and within
 CD the link tag, the endpoint of the RP for accepting IdP(OP/agent)
 CD input.
 
 CD Kind Regards,
 CD Chris Drake
 
 
 CD Tuesday, November 7, 2006, 1:04:44 PM, you wrote:
 
 JE I continue to believe that we need single-sign-out
 JE functionality, in particular once OpenID moves up the stack for
 JE higher-value transactions.
 
 
 JE Some people have made the case that that is undesirable
 JE and/or impossible; I beg to differ.
 
 
 JE Having automatic authentication against the IdP is quite
 JE similar to not having a password on the identity at all, in that
 JE it reduces the confidence that we know the real-world identity of
 JE the entity/user at the other end. In my view, there's nothing
 JE wrong with that, but we do need to be able to convey that to
 JE relying parties in a way that cannot be easily attacked.
 
 
 
 
 
 JE On Nov 6, 2006, at 16:41, Joshua Viney wrote:
 
 JE One question re: User Experience and single-sign-on comes to mind:
 
 
 JE How do we treat users who are accessing their IdP and
 JE Relying Parties via public computers?
 
 
 JE Use Case:
 JE Good User at public library wants to leave a comment on Blog X
 JE Blog X requires the person to authenticate via OpenID
 JE Good User enters their OpenID and successfully authenticates
 JE via email and password (or whatever) (and authorizes the RP
 JE ('realm' in 2.0) if necessary) at their IdP
 JE Good User is redirected to Blog X signed in
 JE Good User leaves comment
 JE Good User signs out of Blog X (if sign out is even an option)
 JE Good User then leaves the public library and goes shopping
 JE Evil User jumps on computer and proceeds to leave comments at
 JE any number of OpenID enabled blogs using Good User's OpenID (he
 JE saw it while looking over Good User's shoulder, or he checks any
 JE sites that Good User did NOT sign out of that might display his
 JE OpenID)
 JE Evil User, uses Good User's signed in IdP session to sign into any
 number of sites, etc
 
 
 JE Outcome: Good User's reputation is ruined and his/her OpenID
 JE is banned from a whole list of Relying Parties. Good User then
 JE blames their IdP, the Relying Parties and OpenID as a technology
 JE and tells everyone he/she knows not to use it blogs about it and
 JE initiates a press release.
 
 
 JE It may be easy to pass this off as an implementation specific
 JE issue or as user error, but this use case is somewhat likely for
 JE 2 reasons:
 
 
 JE 1. A user's OpenID URI is not necessarily a private thing
 JE (obscurity is not security anyway)
 JE 2. Users will be at least 1 site removed from their IdP while
 JE accessing a Relying Party, and no one is use to signing out twice
 JE 3. It is very very likely that IdP's will use some type of remember
 me functionality
 
 
 JE One solution to consider would be a global sign-out feature
 JE on relying party sites that signs users out of their IdP as well.
 JE Another solution would be to make very specific recommendations
 JE about messaging users who may be using public computers.
 
 
 
 
 
 
 JE Josh Viney
 JE http://www.eastmedia.com -- EastMedia
 JE http://identity.eastmedia.com -- OpenID, Identity 2.0
 
 
 
 
 
 
 
 
 JE ___
 JE user-experience

RE: IDMML (was RE: Using email address as OpenID identifier)

2008-04-02 Thread Drummond Reed
  George Fletcher wrote:
 
  I think relying party sites that support OpenID could do more to make
 it
  clear on their home pages that they support OpenID (as often it's
 hidden
  behind another click). This could be as simple as some link tags that
  advertise support for OpenID. Maybe a link to the XRDS doc describing
  the services of the site. Then the identity agent can discover the
  relying party OpenID return_to endpoint and log the user in directly.
  Can be used to solve a phishing problem and makes the experience easy
  for the user.
 
  Some related thoughts 
 http://practicalid.blogspot.com/2007/06/clients-to-rescue.html
 
  http://practicalid.blogspot.com/2007/06/passive-identity-meta-system-
  markup.html
 
  Drummond wrote:
  George, I read your two posts with great interest...and then noticed
 that
  they were last summer!
 
  You are a man ahead of your time.
 
  Where has discussion of your IDMML gone since your posts?
 
 George wrote:
 Unfortunately, not as far as I'd like :(  I've not been able to get back
 to the ideas and take them farther. With the other things that have
 happened in the last 6 months there are needed revisions. Maybe this
 could be a discussion at IIW (if there is enough interest)?
 
 At the time there was less consensus around XRDS as a service
 description/meta-data markup. With that changing, the time is better
 to move this forward. I suspect there are significant synergies with
 what Peter hinted at in the work with XRDS, IDP Discovery, and SAML. It
 would be great if identity agents could be the glue that binds the
 different identity systems together for the user (until we on the
 technology side get closer to real convergence:).

George, I agree that several things have evolved which could make an IDMML
practical now. Seems like a very good topic for IIW. I just put it on the
list of proposed sessions:

http://iiw.idcommons.net/index.php/Proposed_Topics_2008a 

=Drummond 

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


RE: [OpenID] Problems with OpenID and TAG httpRange-14

2008-03-10 Thread Drummond Reed
 -Original Message-
 From: Noah Slater [mailto:[EMAIL PROTECTED]
 Sent: Monday, March 10, 2008 1:43 AM
 To: Drummond Reed
 Cc: specs@openid.net
 Subject: Re: [OpenID] Problems with OpenID and TAG httpRange-14
 
  Noah, you are in the right place (and the General list is the wrong
  place, which is why I have removed that cc).
 
 Okay, thank you.
 
  Once those groups start, they will each have dedicated mailing lists. In
  the meantime, this is the list for discussing any spec issues. So far
  one OpenID Authentication 2.0 editor, Johnny Bufu, has commented on
  the thread you started.
 
 Im a little confused about what this means. Does this mean that this issue
 will not get properly looked at until such time as the new WGs have been
 set up?

It doesn't mean it won't get looked at or discussed here. However any
formal changes to the specifications must wait until these WGs are started.

 Is there anywhere further to go from here?

No, this is the right place, and until the WGs are started, any discussion
should take place on this list.

I'll bring it up at the next OpenID Foundation board meeting (this Thursday)
so board members are aware of this issue.

=Drummond 

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


RE: [OpenID] Problems with OpenID and TAG httpRange-14

2008-03-10 Thread Drummond Reed
Brad,

 

You are correct, the OIDF is not a technical forum. Its responsibility is to
help facilitate the operation of the technical forum and the applicable IPR
policy. The issue I was pointing out was that since the new IPR policy was
adopted in December, which calls for explicit workgroups for each spec, no
place has it been published how those WGs can be formed and operated by
community members in accordance with the IPR policy.

 

So none of this is under the control of the OIDF, but it is their
responsibility to help community members make it happen. I just sent a note
the OIDF board mailing list suggesting this is something that needs
attention on the call this week.

 

=Drummond 

 

  _  

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brad
Fitzpatrick
Sent: Monday, March 10, 2008 11:01 AM
To: Drummond Reed
Cc: Noah Slater; specs@openid.net; [EMAIL PROTECTED]
Subject: Re: [OpenID] Problems with OpenID and TAG httpRange-14

 

Drummond,

I was under the impression that the OpenID Foundation wasn't a technical
forum.  Is that not true?

- Brad

On Mon, Mar 10, 2008 at 10:46 AM, Drummond Reed [EMAIL PROTECTED]
wrote:

 -Original Message-
 From: Noah Slater [mailto:[EMAIL PROTECTED]
 Sent: Monday, March 10, 2008 1:43 AM
 To: Drummond Reed
 Cc: specs@openid.net
 Subject: Re: [OpenID] Problems with OpenID and TAG httpRange-14


  Noah, you are in the right place (and the General list is the wrong
  place, which is why I have removed that cc).

 Okay, thank you.

  Once those groups start, they will each have dedicated mailing lists. In
  the meantime, this is the list for discussing any spec issues. So far
  one OpenID Authentication 2.0 editor, Johnny Bufu, has commented on
  the thread you started.

 Im a little confused about what this means. Does this mean that this issue
 will not get properly looked at until such time as the new WGs have been
 set up?

It doesn't mean it won't get looked at or discussed here. However any
formal changes to the specifications must wait until these WGs are started.


 Is there anywhere further to go from here?

No, this is the right place, and until the WGs are started, any discussion
should take place on this list.

I'll bring it up at the next OpenID Foundation board meeting (this Thursday)
so board members are aware of this issue.

=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: [OpenID] Problems with OpenID and TAG httpRange-14

2008-03-10 Thread Drummond Reed
Exactly, David, that's the process I was referring to.

It should be as lightweight as possible.

I guess the main question is, is there sufficient interest in either a
bugfix release or a more significant new release to start up a mailing list
on OpenID Authentication yet?

=Drummond 

 -Original Message-
 From: David Recordon [mailto:[EMAIL PROTECTED]
 Sent: Monday, March 10, 2008 12:15 PM
 To: Drummond Reed; Brad Fitzpatrick
 Cc: Noah Slater; OpenID specs list; DeWitt Clinton
 Subject: Re: [OpenID] Problems with OpenID and TAG httpRange-14
 
 I don't see why changes would really need to wait, if there is an
 interested group of people then lets spin up a mailing list and get
 participants to agree to the IP policy.
 
 The entire goal of having working groups and seperate mailing lists
 is to help ensure that future OpenID specs are not encumbered with
 intellectual property issues.  The easiest, and most common, way to do
 this is creating seperate technical working mailing lists based around
 related topics or a specification.  This allows people to choose where
 they wish to participate since the requirement of posting to one of
 these lists is agreeing that your contributions are being made under
 the OpenID IPR Policy.
 
 This list (specs@openid.net) is a great place to identity issues that
 need addressing and figuring out who wants to work on solving them.
 Once that happens, I have no problem helping to make it legit so
 that the resulting spec is good from an IP perspective.
 
 --David
 
 On Mar 10, 2008, at 12:46 PM, Drummond Reed wrote:
 
  -Original Message-
  From: Noah Slater [mailto:[EMAIL PROTECTED]
  Sent: Monday, March 10, 2008 1:43 AM
  To: Drummond Reed
  Cc: specs@openid.net
  Subject: Re: [OpenID] Problems with OpenID and TAG httpRange-14
 
  Noah, you are in the right place (and the General list is the wrong
  place, which is why I have removed that cc).
 
  Okay, thank you.
 
  Once those groups start, they will each have dedicated mailing
  lists. In
  the meantime, this is the list for discussing any spec issues. So
  far
  one OpenID Authentication 2.0 editor, Johnny Bufu, has commented on
  the thread you started.
 
  Im a little confused about what this means. Does this mean that
  this issue
  will not get properly looked at until such time as the new WGs have
  been
  set up?
 
  It doesn't mean it won't get looked at or discussed here. However
  any
  formal changes to the specifications must wait until these WGs are
  started.
 
  Is there anywhere further to go from here?
 
  No, this is the right place, and until the WGs are started, any
  discussion
  should take place on this list.
 
  I'll bring it up at the next OpenID Foundation board meeting (this
  Thursday)
  so board members are aware of this issue.
 
  =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


Public Review of Extensible Resource Identifier (XRI) Resolution V 2.0 - 15 day review

2008-03-10 Thread Drummond Reed
FYI - XRI Resolution 2.0 is now undergoing one more 15-day public review
after incorporation of feedback from the previous 60-day public review in
December and January. Links to both the change-marked and clean version of
the spec are in the announcement below.

=Drummond 

-Original Message-
From: Mary McRae [mailto:[EMAIL PROTECTED] On Behalf Of Mary McRae
Sent: Monday, March 10, 2008 6:31 PM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: [members] Public Review of Extensible Resource Identifier (XRI)
Resolution V 2.0 - 15 day review

To OASIS members, Public Announce Lists:

The OASIS eXtensible Resource Identifier (XRI) TC has recently approved the
following specification as a Committee Draft and approved the package for
public review:

Extensible Resource Identifier (XRI) Resolution Version 2.0

The public review starts today, 11 March 2008, and ends 26 March 2008. This
specification was previously submitted for a 60-day public review on 2
December 2007[1]; this 15-day review is limited in scope to changes made
from the previous review. All changes are highlighted. 

This is an open invitation to comment. We strongly encourage feedback from
potential users, developers and others, whether OASIS members or not, for
the sake of improving the interoperability and quality of OASIS work.

More non-normative information about the specification and the technical
committee may be found at the public home page of the TC at: 
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xri. Comments may
be submitted to the TC by any person through the use of the OASIS TC Comment
Facility which can be located via the button marked Send A Comment at the
top of that page, or directly at: 
http://www.oasis-open.org/committees/comments/index.php?wg_abbrev=xri.

Submitted comments (for this work as well as other works of that TC) are
publicly archived and can be viewed at: 
http://lists.oasis-open.org/archives/xri-comment/. All comments submitted to
OASIS are subject to the OASIS Feedback License, which ensures that the
feedback you provide carries the same obligations at least as the
obligations of the TC members.

The specification document and related files are available here:

Change-Marked/Comments:
http://docs.oasis-open.org/xri/xri-resolution/2.0/specs/cd03/xri-resolution-
V2.0-cd-03-diff.doc

Editable Source (Authoritative):
http://docs.oasis-open.org/xri/xri-resolution/2.0/specs/cd03/xri-resolution-
V2.0-cd-03.doc

PDF:
http://docs.oasis-open.org/xri/xri-resolution/2.0/specs/cd03/xri-resolution-
V2.0-cd-03.pdf

HTML:
http://docs.oasis-open.org/xri/xri-resolution/2.0/specs/cd03/xri-resolution-
V2.0-cd-03.html


The RelaxNG schema files, that are included normatively in the specification
document, are available as separate files at:
http://docs.oasis-open.org/xri/xri-resolution/2.0/specs/cd03/xrd.rnc
http://docs.oasis-open.org/xri/xri-resolution/2.0/specs/cd03/xrds.rnc

Additionally, W3C schema files are available as separate files at:
http://docs.oasis-open.org/xri/xri-resolution/2.0/specs/cd03/xrd.xsd
http://docs.oasis-open.org/xri/xri-resolution/2.0/specs/cd03/xrds.xsd 

OASIS and the eXtensible Resource Identifier (XRI) TC welcome your comments.


---
Mary P McRae
Manager of TC Administration, OASIS
email: [EMAIL PROTECTED]  
web: www.oasis-open.org 

[1] http://lists.oasis-open.org/archives/tc-announce/200712/msg2.html 


-


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


RE: Integration with Enterprise Directory Services

2008-01-25 Thread Drummond Reed
+1. Since the results would apply to both URLs and XRIs, I expect several
XRI TC members would be willing to help review such guidelines.

=Drummond 

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
 Of John Ehn
 Sent: Friday, January 25, 2008 3:34 PM
 To: McGovern, James F (HTSC, IT)
 Cc: specs@openid.net
 Subject: Re: Integration with Enterprise Directory Services
 
 James,
 
 It appears you possess a good amount of knowledge on this topic.
 
 I believe that if you were to come up with some preliminary
 implementation guidelines (and presented them here for review), you
 would not be stepping on anyone's toes.
 
 Thank you,
 
 John Ehn
 
 On Jan 25, 2008, at 3:59 PM, McGovern, James F (HTSC, IT)
 [EMAIL PROTECTED]
   wrote:
 
  Is there merit in also defining other aspects such as how the OP would
  store history in LDAP by defining new ObjectClass?
 
 
  ***
  **
  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: Integration with Enterprise Directory Services

2008-01-24 Thread Drummond Reed
Yes, Marty Schleiff at Boeing is working on an RFC for how to represent XRIs
in an LDAP directory for that very reason -- to establish standard OIDs for
this attribute. LDAP already has a URI attribute type, but downcasting an
XRI into a URI just to squeeze it into that attribute type loses the
semantics that the XRI is an abstract identifier for the resource. So Boeing
wants to establish OIDs for primary-xri (value of the canonical XRI) and
alt-xri (value of any other XRI synonym).

OpenID URLs really have the same problem -- yes, they are URLs, but they are
URLs with the specific property of being OpenID URLs. The LDAP URI attribute
doesn't have that semantics.

I don't think Marty's on this list but I'm cc'ing him.

=Drummond 


 -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
 Of McGovern, James F (HTSC, IT)
 Sent: Thursday, January 24, 2008 10:12 AM
 To: Johannes Ernst
 Cc: specs@openid.net
 Subject: RE: Integration with Enterprise Directory Services
 
 Would even take it to ensuring that directories use a common OID and not
 just making up their own attribute. Staying equivalent to Cardspace is a
 good thing.
 
 -Original Message-
 From: Johannes Ernst [mailto:[EMAIL PROTECTED]
 Sent: Thursday, January 24, 2008 1:00 PM
 To: McGovern, James F (HTSC, IT)
 Cc: specs@openid.net
 Subject: Re: Integration with Enterprise Directory Services
 
 This doesn't necessarily belong into the core protocol specs, as many
 implementations will store OpenIDs in places other than directories.
 
 However, it would make sense to have a common convention for that ...
 perhaps a separate 1-page standard?
 
 
 On Jan 24, 2008, at 7:02, McGovern, James F (HTSC, IT) wrote:
 
  For CardSpace, MS and other providers store it in the SeeAlso
  attribute. Figured OpenID in the next rev of the spec should talk more
 
  about implementation details.
 
  -Original Message-
  From: Drummond Reed [mailto:[EMAIL PROTECTED]
  Sent: Wednesday, January 23, 2008 11:57 PM
  To: McGovern, James F (HTSC, IT); specs@openid.net
  Subject: RE: Integration with Enterprise Directory Services
 
  James, are you asking about the recommended format for saving an
  OpenID identifier in an LDAP directory? If so, I know Boeing has done
  some work in that area -- I can check with their directory guru.
 
  =Drummond
 
  -Original Message-
  From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
  Behalf Of McGovern, James F (HTSC, IT)
  Sent: Wednesday, January 23, 2008 1:47 PM
  To: specs@openid.net
  Subject: Integration with Enterprise Directory Services
 
  What is the standard recommendation for how identifiers get stored in
 
  enterprise directory services (e.g. LDAP)?
 
 


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


RE: Integration with Enterprise Directory Services

2008-01-23 Thread Drummond Reed
James, are you asking about the recommended format for saving an OpenID
identifier in an LDAP directory? If so, I know Boeing has done some work in
that area -- I can check with their directory guru.

=Drummond 

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
 Of McGovern, James F (HTSC, IT)
 Sent: Wednesday, January 23, 2008 1:47 PM
 To: specs@openid.net
 Subject: Integration with Enterprise Directory Services
 
 What is the standard recommendation for how identifiers get stored in
 enterprise directory services (e.g. LDAP)?
 
 
 
 *
 This communication, including attachments, is
 for the exclusive use of addressee and may contain proprietary,
 confidential and/or privileged information.  If you are not the intended
 recipient, any use, copying, disclosure, dissemination or distribution is
 strictly prohibited.  If you are not the intended recipient, please notify
 the sender immediately by return e-mail, delete this communication and
 destroy all copies.
 *
 
 ___
 specs mailing list
 specs@openid.net
 http://openid.net/mailman/listinfo/specs

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


RE: Service Key Discovery 1.0

2008-01-21 Thread Drummond Reed
Masaki, Peter has a good point -- the XRDS keyinfo discovery mechanism,
specified in section 10.2 (SAML Trusted Resolution) of XRI Resolution 2.0
Committee Draft 02
(http://docs.oasis-open.org/xri/2.0/specs/cd02/xri-resolution-V2.0-cd-02.pdf
), deals with DNS poisoning by using signed SAML assertions (including the
ds:keyInfo element) for each authority in the resolution chain. So presuming
HTTPS is used for the first root authority call, you should be good all the
way down the chain as long as signatures verify.

(Peter's also right that libraries have not implemented it yet, but that may
be changing soon as demand for secure key discovery rises...)

=Drummond 

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
 Of Peter Davis
 Sent: Monday, January 21, 2008 6:33 AM
 To: NISHITANI Masaki
 Cc: specs@openid.net
 Subject: Re: Service Key Discovery 1.0
 
 FWIW, the XRI form of openID's provides just such a mechanism, where-
 by the publisher of the XRD signs all (or a part of) the XRDS, tho i
 know of few libraries today which support trusted resolution[1].
 
 =peterd
 
 [1] http://docs.oasis-open.org/xri/2.0/specs/cd02/xri-resolution-V2.0-
 cd-02.pdf
 
 
 On Jan 21, 2008, at 5:38 AM, NISHITANI Masaki wrote:
 
  Hi all.
  What concerns me these days is about secure data exchange
  over OpenID for serious services and about this theme, I
  came upon an specification, secure key discovery 1.0
 
  For my understanding, this spec is about implementing
  security framework on OpenID world and is still very draft.
 
  Now I'd like to figure out some point I found.
 
  - In this, the url of the public key is defined to be in the
XRD document and entities will make another request for
the url to retrieve the public key itself.
This gives bad people a chance to pass off a fake key with
poisoning the end-user's DNS. How about to put public key
itself in the XRD or someone else the entity trusts (a
key server)?
The entity only has to manage SSL certificate fingerprints
of XRD authorities or trusting key servers.
 
  - With secure key discovery, we do have to use
association or verification message no longer.
I think we can optimize OpenID protocol using digital
signature with public keys. This can be done with
following procedure.
 
1. End-user enter its OpenID in RP site.
2. RP resolve the id and select the user's OP.
3. In the same time, RP retrieve the OP's public key.
4. RP generate a challenge (maybe the user's http session
   id)
5. RP send the id to the OP via http redirection.
6. OP authenticate the user and sign to the challenge with
   OP's secret key.
7. OP send the assertion including the signed challenge
   back to the RP via redirection.
8. Now RP can verify the assertion with the signature
   using OP's public key.
 
The good thing about this sequence is not only reducing
network traffic, but this can be a solution against
man-in-the-middle attacks, to which OpenID has principle
vulnerability.
 
  I think this spec can be quite useful for the next version
  of OpenID protocol.
  Does someone know the status of it?
 
 
  =masaki
 
  ___
  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 Email Discovery

2008-01-03 Thread Drummond Reed
Phillip, what do you mean by Until the IPR commitments necessary to allow
that change are made there is no standard. The OASIS XRI TC has operated
under a royalty-free IPR policy since the day it was formed (see the
language in the charter,
http://www.oasis-open.org/committees/xri/charter.php), and subsequently
adopted to the RF Limited IPR Policy when OASIS update its IPR rules
(document at http://www.oasis-open.org/committees/xri/ipr.php). 

 

So even though the final spec in the XRI 2.0 suite - XRI Resolution 2.0
Committee Draft 02 - is now in public review
(http://lists.oasis-open.org/archives/xri/200712/msg1.html), so we
should be proceeding to an OASIS Standard vote on XRI 2.0 this spring, there
shouldn't be anything standing in the way of immediate adoption, as has been
happening in a number of open source efforts.

 

Or is there something about the OASIS standardization process that I'm
missing?

 

=Drummond 

 

  _  

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 
 

RE: [Idschemas] identity schema element metadata:using existingspecifications

2007-09-10 Thread Drummond Reed
+1 to Nat's point about supporting virtual aggregation under user control.

Chris, on the larger question you ask, the Data Sharing Summit was not about
how others that have your data can share it, but rather about how you can
control and share that data the way you want with whom you want.

To be clear, not all the attendees of the DSS subscribe to your vision of
100% user-centric aggregation. A number of them were services that provide
some type of aggregation in which the user is in control, but the site is
still able to offer services/applications/other-value-adds based on doing
this aggregation on the user's behalf. Several new social network
aggregation services like Pownce have this philosophy.

They would say that the user elects to trust them as a service provider just
like the user elects to trust an IdP (or OP as OpenID calls them).

Anyway, I just wanted to clear up any misconception about what the Data
Sharing Summit was about. Without that context, I agree that name could
make it look like a really Bad Idea.

=Drummond 

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
 Of Nat Sakimura
 Sent: Sunday, September 09, 2007 10:18 PM
 To: Chris Drake
 Cc: 'OpenID specs list'; 'ID Schemas'
 Subject: Re: [Idschemas] identity schema element metadata:using
 existingspecifications
 
 Hi,
 
 Instead of having one single master copy at the IdP, I would prefer one
 single piece of each information disparsed over the network (optionally
 with opaque identifiers) and having IdP managing the links so that I
 can control all the pieces from one place. I feel that having everything
 at one place is too risky.
 
 =nat
 
 Chris Drake wrote:
  Hi,
 
  Having missed the summit - can anyone tell if there was any dissent or
  scaremongering going on?  The idea of assisting everyone who's
  collecting information about me, to share it easily, seems like an
  exceptionally Bad Idea (tm).
 
  If anyone's building anything that assists these companies to give
  up or relinquish their collection of my data, in favor of letting me
  hold the one single master copy if it myself, on my chosen IdP, and to
  let me arbitrate who can use it, when, and how - now *that* would be
  something to congratulate people about.
 
  Search google/google-news for paper shredder ...
 
  Kind Regards,
  Chris Drake,
  =1id.com
 
 
  Saturday, September 8, 2007, 5:33:20 PM, you wrote:
 
  DR Mark,
 
  DR I just wanted to say that based on what I learned about them at the
 Data
  DR Sharing Summit (http://datasharingsummit.com) today, and what I read
 on my
  DR first pass tonight, these are fine pieces of work that really push
 the ball
  DR forward.
 
  DR Hats off to you.
 
  DR =Drummond
 
 
  -Original Message-
  From: [EMAIL PROTECTED] [mailto:idschemas-
  [EMAIL PROTECTED] On Behalf Of Mark Wahl
  Sent: Thursday, September 06, 2007 6:05 PM
  To: ID Schemas
  Cc: OpenID specs list
  Subject: [Idschemas] identity schema element metadata: using
  existingspecifications
 
 
  I'm reformatting the table of identity schema metadata, located at
  http://idschemas.idcommons.net/moin.cgi/MetaData, into a
  pair of more compact and usable specifications. One spec describes
  where the existing well-known metadata (e.g., Dublin Core) should be
  used when describing identity schemas and their schema elements (i.e.,
  attribute types and claim types).  The other spec will describe how
  to represent identity schema metadata for which there is no
  pre-existing well-known specification.  I've attached a copy of
  the first draft of the Identity Schema Element Metadata: Using
  Existing Specifications.
 
  Mark Wahl
  Informed Control Inc.
 
 
 
 
  DR ___
  DR specs mailing list
  DR specs@openid.net
  DR 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: Do We Agree on the Problem We're Trying to Solve?

2007-06-08 Thread Drummond Reed
Multiple, redundant identifiers is what canonical ID mapping provides. It
doesn't require a master directory; it's as distributed as OpenID itself,
i.e., it simply provides a way to map a reassignable URL or XRI to a
persistent URL or XRI.

Given the right practices, it solves both A and B. The cost can be, as Josh
points out, an extra round trip on discovery. However this can be avoided
for certain pairs of the reassignable and persistent identifiers. See my
next reply to Josh's message.

=Drummond 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Dick Hardt
Sent: Friday, June 08, 2007 12:33 PM
To: Johannes Ernst
Cc: specs@openid.net
Subject: Re: Do We Agree on the Problem We're Trying to Solve?

Multiple, redundant identifiers solves B without requiring a master  
directory.

On 8-Jun-07, at 11:06 AM, Johannes Ernst wrote:

 Such as?

 On Jun 8, 2007, at 10:55, Dick Hardt wrote:

 There are ways to solve B that don't really solve A.

 In fact, I think the only way to solve B that does not require a
 master directory is orthogonal to solving A.

 -- Dick

 On 8-Jun-07, at 10:49 AM, Johannes Ernst wrote:

 I would suggest that any solution to B is also very likely a
 solution to A.

 Anybody disagree?

 If so, I'd suggest that we should either solve A and B at the same
 time, or not at all.



 On Jun 8, 2007, at 10:42, Dick Hardt wrote:

 At IIW we[1] decided we wanted to solve (A) and that (B) would be
 nice to solve, but we were ok to wait for a future version to
 resolve, as when we discussed (B), resolving looked much harder  
 then
 it seemed at first.

 I'm not certain of where we are now.

 -- Dick

 [1] those present when we met about how to solve recycling ...

 On 8-Jun-07, at 10:35 AM, Recordon, David wrote:

 I'm not sure if we all think we're trying to solve the same  
 problem.
 The two problems that have been discussed are:
 A) Identifier recycling normally in large user-base deployments.
 i.e.
 insert big company needs a way to give 'TheBestUsernameEver'  
 to a
 new
 user if it has not been used in some period of time.
 B) Losing control of your own domain name whether that be via
 someone
 stealing it or just that you don't want to have to pay for it
 forever.

 Have we made a decision as to if we're looking for a solution to
 solve
 both of these problems, only A, or only B?

 --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



 ___
 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: Do We Agree on the Problem We're Trying to Solve?

2007-06-08 Thread Drummond Reed

 Dick Hardt wrote:

 Canonical IDs do not solve B.

I would agree with that one.

Obviously the XRI architecture assumption (not as radically  
decentralized as OpenID) makes that less of a problem in an XRI  
context. Of course, some would say that that assumption is a problem  
in itself.

Where was it asserted that XRI architecture is not as radically
decentralized as OpenID? Fen made the point yesterday that XRI architecture
is *less* centralized that DNS. The choice of identifier authorities under
URL architecture is DNS registries or IP addresses. XRI architecture
supports both of those and adds two more: XRI registries and p2p
authorities. So it's getting less centralized, not more.

Due to the influence of OpenID and other URL-centric technologies, in the
XRI 3.0 discussions already under way, the TC is looking at formalizing XRI
resolution of HTTP and HTTPS URIs (URLs) and Handles. Wouldn't it be cool
for OpenID libraries be able to simply call a resolver to do XRDS resolution
of any OpenID identifier (URL or XRI), Canonical ID verification (URL or
XRI), and OpenID service endpoint selection all in one function?

=Drummond 

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


RE: Do We Agree on the Problem We're Trying to Solve?

2007-06-08 Thread Drummond Reed

 Drummond Reed wrote:

 Multiple, redundant identifiers is what canonical ID mapping  
 provides. It
 doesn't require a master directory; it's as distributed as OpenID  
 itself,
 i.e., it simply provides a way to map a reassignable URL or XRI to a
 persistent URL or XRI.

Dick Hardt wrote:

The persistent URL or XRI *is* a master directory. What do you do  
when the persistent identifier is compromised, goes out of business ...

That is problem B.

Canonical IDs do not solve B.

I completely agree that B is a hard problem. However Canonical IDs solve B
if the identifier authority for the Canonical ID follows business and
operational practices intended to solve B.

For example -- and this is only one example, other identifier authorities
that adopt these or similar practices to solve B -- XDI.org spent several
years developing policies that ensure that as an identifier authority, the
Canonical IDs (global i-numbers) assigned by the XDI.org global XRI
registries follow these policies:

1) Global i-numbers and their registration policie are designed explicitly
for persistent identifiers that are never reassigned and administered by an
international public trust organization (XDI.org) for which this is the
primary responsibility.

2) If the i-broker serving as the end-user's registrar goes out of business,
the global i-number is not compromised because, like a DNS name, it is
portable, i.e., the registrant can move it to another accredited i-broker.
In other words, the concern about going out of business becomes a concern
only about the entire infrastructure going out of business.

3) Strong authentication is used in i-broker-to-registry communications to
ensure that only accredited and authoritative i-brokers make changes to
global registrations, and accredited i-brokers compete under market
conditions to offer the best and most flexible means of authenticating
registrants, thereby minimizing the risk of a registrant losing control of
their global i-number.

4) Every global i-number registration also enables the registrant to
register private contact data with an independent third-party trustee (their
contact data custodian) to provide an independent third-party channel for
authentication.

For reference, see the XDI.org Global Services Specifications site at
http://gss.xdi.org. 

It's not a perfect solution, but I would argue (my well-known bias aside)
that it's a practical one.

=Drummond 

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


RE: Specifying identifier recycling

2007-06-03 Thread Drummond Reed

 Johnny Bufu wrote:
 
 We did look at this (with Drummond) in December. The bottom line is  
 that it can't be done easily - a mechanism similar to XRI's canonical  
 ID verification would have to be employed, to confirm that the i- 
 number actually 'belongs' to the URL on which discovery was  
 initiated. (Otherwise anyone could put any i-number in their URL- 
 based XRDS files.)
 
Martin Atkins wrote:

Indeed, CanonicalID verification would be necessary, but it's already 
necessary if you want to accept XRI-based logins anyway.

Last time we were talking about this CanonicalID verification for XRI 
was not yet specified. Is it now specified somewhere?

Martin, it's been specified in draft form since last October on the XRI TC
wiki at:

http://wiki.oasis-open.org/xri/XriCd02/CanonicalIdVerification

The content there was moved week before last into the first editor's draft
of XRI Resolution 2.0 Working Draft 11 at:


http://www.oasis-open.org/committees/download.php/24096/xri-resolution-v2.0-
wd-11-ed-01.doc

The new Canonical ID Verification section is #11. Note that the verification
rules currently only cover if the XRDS is discovered from an XRI. In the
second editor's draft, due this Wednesday, we will add rules for
verification if the XRDS is discovered from a URL.

=Drummond 

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


RE: Review of Yadis section in XRI Resolution 2.0 WD11

2007-05-31 Thread Drummond Reed
Johnny, David, Rowan:

Thanks much for the excellent feedback. I'm tied up in meetings through
tomorrow but by Monday I'll make the suggested updates and roll this into
the second editor's draft of XRI Resolution 2.0 Working Draft 11, which we
aim to post by next Wednesday.

=Drummond 

-Original Message-
From: Johnny Bufu [mailto:[EMAIL PROTECTED] 
Sent: Thursday, May 31, 2007 7:52 PM
To: Recordon, David
Cc: Drummond Reed; OpenID specs list
Subject: Re: Review of Yadis section in XRI Resolution 2.0 WD11


On 31-May-07, at 5:34 PM, Recordon, David wrote:
 I'd recommend adding a section which pulls together the HEAD and GET
 methods and describes how'd they be used in conjunction.

In the interest of keeping it light and simple to process, I believe  
it would be enough to make this explicit just before 8.1 by saying  
that any of the two protocols MAY be attempted by an RP (plus fixing  
the fallback from HEAD to GET).

 Also explicitly pointing out that a URL hosting a XRDS document  
 only is
 required to implement one or more of the discovery mechanisms

Not one or more; GET is REQUIRED, HEAD is OPTIONAL in Yadis. This  
too can be specified inline in sections 8.1 / 8.2.

 whereas a service requesting XRDS documents must implement all of  
 the different
 methods.

An RP may choose to only do GET and not care about the more efficient  
(but optional on the server side) HEAD.


Johnny


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


RE: Specifying identifier recycling

2007-05-30 Thread Drummond Reed

 John Panzer wrote:

 Has there been a discussion about an extension to map to/from i- 
 numbers
 via AX?  If there were a generic attribute you could stuff an i- 
 number
 or a hash of an internal ID in there to help solve the disambiguation
 problem.  Alternatively it'd be nice to have a way to ask when the
 account was created, if the OP is amenable.

 Martin Atkins wrote

 If you're going to use i-numbers, then there's no reason at all not to
 use the XRD CanonicalID element. The same mechanism that's used to map
 i-names onto i-numbers can also be used to map URLs onto i-numbers, or
 URLs onto other URLs.

 I'm sure Drummond can talk in more detail about this. We did  
 discuss it
 briefly at IIW, but once the majority had decided that the fragment
 approach was the way to go we didn't get a chance to investigate this
 further.

Johnny Bufu wrote;

We did look at this (with Drummond) in December. The bottom line is  
that it can't be done easily - a mechanism similar to XRI's canonical  
ID verification would have to be employed, to confirm that the i- 
number actually 'belongs' to the URL on which discovery was  
initiated. (Otherwise anyone could put any i-number in their URL- 
based XRDS files.)

Johnny:

Martin, Gabe, and I discussed this at IIW, and the CanonicalID verification
process that's specified in the XRI Resolution 2.0 Working Draft 11
specification (of which the first editor's draft has now been posted - see
below) could be applied even if the XRDS was discovered via a URL.

To do this, RP code would need to confirm the CanonicalID i-number was
authoritative for the XRDS, which is essentially the same process the RP has
to go through anyway when the OP returns a different identifier than the one
the user originally entered at the RP (such as in the directed identity
flow).

In the first editor's draft of WD11, we only specified Canonical ID
verification when an XRDS was discovered from an XRI. But in the second
editor's draft (due early next week), we could add text specifying how to do
Canonical ID verification when the XRDS is discovered from a URL.

Although it's not yet content complete, you can review the Canonical ID
verification section (section 11) as well as the Yadis section (section 8)
in the first editor's draft of WD11 at:


http://www.oasis-open.org/committees/download.php/24096/xri-resolution-v2.0-
wd-11-ed-01.doc 

To make it easier to review, we've also posted section 8 (the Yadis section)
as a wiki page on the XRI TC wiki. See my next message about that.

=Drummond 

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


RE: Specifying identifier recycling

2007-05-30 Thread Drummond Reed
Johannes:

What about the point Dick posted earlier in this thread, that the problem
with using a public key is if the private key gets compromised? Persistent
identifiers need to persist independent of any attribute changing or being
revoked.

=Drummond 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Johannes Ernst
Sent: Wednesday, May 30, 2007 9:54 PM
To: OpenID specs list
Subject: Re: Specifying identifier recycling


On May 30, 2007, at 21:02, Johnny Bufu wrote:

 ...The bottom line is
 that it can't be done easily - a mechanism similar to XRI's canonical
 ID verification would have to be employed, to confirm that the i-
 number actually 'belongs' to the URL on which discovery was
 initiated. (Otherwise anyone could put any i-number in their URL-
 based XRDS files.)

Public keys ... public keys ... with the added benefit that no  
centralized or trusted verification service needs to be employed  
whatsoever ...




Johannes Ernst
NetMesh Inc.



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


Review of Yadis section in XRI Resolution 2.0 WD11

2007-05-30 Thread Drummond Reed
As discussed at IIW, the OASIS XRI TC is now moving swiftly to close and
vote on the XRI Resolution 2.0 spec (which has been at the Working Draft 10
stage during the entire evolution of OpenID Authentication 2.0) so it can be
referenced by OpenID Authentication 2.0 when it goes final.

To that end, the first editor's draft of Working Draft 11 has been posted
[1]. It's not quite content complete (all major changes have been
incorporated; we're now working on the smaller stuff), so we're not asking
folks to review the whole thing yet (many OpenID folks think it's too long
anyway ;-).

However it would be great to get feedback on the new section 8 that
incorporates the Yadis protocol. Per discussions with the OpenID editors
last fall, the XRI TC is including this in the XRI Resolution spec so
everything about XRDS documents and their discovery is referenceable in an
open public OASIS spec, even if only URLs and no XRIs are involved.

To make this new section easy to review, we've put it on the XRI TC wiki at:

http://wiki.oasis-open.org/xri/XriCd02/XrdsDiscoveryFromHttpUris 

It's pretty short and sweet, mostly because XRDS documents and their context
and usage are defined elsewhere in the spec. So this section just defines
the URL-based discovery protocol, which is the meat of the Yadis 1.0 spec.
The wording has been restructured slightly to fit the OASIS spec format,
however the only normative change was to make the recommendation to include
the application/xrds+xml Accept header in the HEAD or GET request a SHOULD
instead of a MAY. The XRI TC felt this was justified to encourage efficiency
-- feel free to push back if you think that's the wrong call.

Since only XRI TC members can write to the wiki (due to OASIS IPR rules),
please post any feedback here on the specs list and we'll reflect it on the
wiki page as quickly as we can (I myself will be offline in meetings
tomorrow but back online tomorrow night).

Thanks,

=Drummond 

[1]
http://www.oasis-open.org/committees/download.php/24096/xri-resolution-v2.0-
wd-11-ed-01.doc 

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


RE: attribute exchange value encoding

2007-05-25 Thread Drummond Reed
Johnny Bufu wrote:

While at IIW, I asked around what people thought about the encoding  
mechanisms we've added recently, in order to allow for transferring  
any data types. The consensus was that everyone would prefer  
something simpler and lighter.

So I've rewritten the encoding section, such that:

- for strings, only the newline (and percent) characters are required  
to be escaped,
   (to comply with OpenID's data formats), using percent-encoding;

- base64 must be used for encoding binary data, and defined
   an additional field for this:
   openid.ax.encoding.alias=base64

Please review section 3.3 Attribute Values to see if there are any  
issues.

One remaining question is about the choice of encoding for strings.  
Percent-encoding (RFC3968) seems the simplest from a spec  
perspective, however some libraries provide (better) support for the  
older URL-encoding (RFC1738), which throws '+' characters into the  
mix. Which do you think would work best for implementers, users, and  
would cause less interop problems?

Johnny,

FWIW, encoding + can be a hassle as it's a legal character in media type
values and is also sometimes used for spaces. I'd vote for pure RFC3986
percent-encoding.

=Drummond 

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


RE: HTML discovery: SGML entities and charsets

2007-05-23 Thread Drummond Reed
Peter Watkins wrote:

snip

My concrete suggestion: replace the current language

Other characters that would not be valid in the HTML document or that
cannot be represented in the document's character encoding MUST be escaped
using the percent-encoding (%xx) mechanism described in [RFC3986].

with this:

Any character in the href attributes MAY be represented as UTF-8 data
escaped using the percent-encoding (%xx) mechanism described in [RFC3986].
Characters with Unicode values greater than u007E MUST be represented as
UTF-8 data escaped using the percent-encoding (%xx) mechanism described in
[RFC3986]. For instance, the character ä (umlaut a, Unicode u00E4) MUST be
represented as a six-character string like %C3%A4 as suggested by RFC2718.


Peter, I agree UTF-8 encoding before percent-encoding must be specified, as
otherwise you don't know how to interpret the percent-encoded characters.
However, since RFC 3987 (the IRI spec) already specifies UTF-8 encoding
before percent-encoding, couldn't we just specify it by reference to both
RFC 3986 and 3987, e.g.:

Any character in the href attributes MUST be a valid URI character as
specified by [RFC3886]. If any character outside the valid URI character set
is included, it MUST be encoded using the percent-encoding (%xx) mechanism
defined in section 2.1 of [RFC3986] after first being UTF-8 encoded as
specified in [RFC3987]. For instance, the character ä (umlaut a, Unicode
u00E4) MUST be represented as a six-character string like %C3%A4 as
suggested by RFC2718.

=Drummond 

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


RE: PROPOSAL schema.openid.net for AX (and other extensions)

2007-04-10 Thread Drummond Reed
On 9-Apr-07, at 5:24 PM, Recordon, David wrote:

 Yes, I agree an upgrade path from SREG is needed.  We could however do
 something as simple as
 http://openid.net/specs/openid-simple-registration- 
 extension-1_0.html#ni
 ckname for the existing SREG fields.

Dick wrote:

by making this a fragment, you force a requirement that Mark's tool  
has to be able to dig into a document and find the anchor as opposed  
to the attribute being self contained -- a complication I am not sure  
we want to deal with at this point in the meta-data

why not have a page that maps the existing SREG to the AX attributes  
we have already defined? why create yet-another set of attributes?

Myself, I think a developer would like to look in ONE place to find  
all the common web related attributes she will likely need so that  
she can build her app and not have to go looking across a dozen  
different sources to write some code.

There will definitely be attributes that are for specific  
communities, so the developer will need to look in a few places, but  
why make it harder then it needs to be at this point in time?

A number of people have spoken up to vote +1 to use  
schema.openid.net. Given that you have the magic wand David, are you  
going to let the community progress or do we have to keep arguing  
with you until one party wears out and gives up?

I haven't spoken up yet, but I feel strongly that creating YAAD (Yet Another
Attribute Dictionary) for OpenID is a bad idea. OpenID is a wonderful force
for driving towards attribute dictionary convergence, but that is not the
focus of OpenID. It is however the direct focus of the Identity Commons
Identity Schemas Working Group (site: http://idschemas.idcommons.net/,
charter: http://wiki.idcommons.net/moin.cgi/IdentitySchemasCharter). 

Since the problem of attribute interop is larger than OpenID, I strongly
recommend that those of us in the OpenID community that want to see this
problem solved join the idschemas mailing list
(http://mail.idcommons.net/cgi-bin/mailman/listinfo/idschemas) and work out
the attribute dictionary (complete with synonyms) there. That way OpenID,
CardSpace, XDI, and any technology that needs to move around standard
profile data will have half a prayer of actually doing it interoperably.

=Drummond 

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


RE: in favor of allowing a fragment in a URI for metadata for anattribute type

2007-04-10 Thread Drummond Reed
+1 as well. Very well articulated.

An interesting side note: XRI supports a # fragment for backward
compatibility with URI/IRI syntax, but in practice its rarely used since XRI
syntax is already polyarchical, i.e., any XRI can be put in the context of
another XRI. # is just one such context (document local). So XDI
dictionaries, which use XRIs to identify attributes, can have all the same
general properties that Mark describes (except #5, which applies only to
URLs), only they don't have to explicitly be expressed as fragments.

=Drummond 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Dick Hardt
Sent: Tuesday, April 10, 2007 5:53 PM
To: Mark Wahl
Cc: OpenID specs list; ID Schemas
Subject: Re: in favor of allowing a fragment in a URI for metadata for
anattribute type

Good argument Mark, I concur. +1

-- Dick

On 10-Apr-07, at 4:52 PM, Mark Wahl wrote:


 Section 4.3 of
 http://openid.net/specs/openid-attribute-types-1_0-02.html
 suggests that in URIs defined for attributes for OpenID AX,
 URI fragment specifiers should not be used.

 Now I'm no RDF expert, but I'm in favor of allowing fragments,
 and perhaps even encouraging them. I'd prefer this statement
 be removed from subsequent versions of the OpenID AX, in order
 to not dissuade other schema developers from using fragments.
 Here are some points for discussion on that topic, I'd be
 interested in hearing feedback esp. from other RDF implementors.

 0. Some servers will have but a single, small, fixed schema.  I'd
 rather those servers be able to reference and serve a single RDF
 file with their complete schema, instead of needing to break that
 schema into a bunch of little schemas.

 For example, suppose a server only supports FOAF.  Now FOAF does not
 use fragments for the property definitions for its attribute types,
 but the attribute types defined in FOAF are not currently resolvable
 to an RDF document that describes those attribute types.

 If xmlns.com where the FOAF RDF is hosted were to implement having  
 these
 attribute type URIs used in FOAF be resolvable, they
 would either need to
   - create a few dozen little RDF files that together mirror the  
 content of
 foaf.rdf, or
   - implement a URI rule that http://xmlns.com/foaf/0.1/*
 returns foaf.rdf

 If I were redefining FOAF, I'd have its attributes be defined as  
 fragments,
 so that there is only one base URI for the FOAF schema.  (Also to give
 them RDF class definitions, see below).

 1. It appears to be current practice for RDF representations of  
 metadata
 for attributes in Higgins to use fragments.

 In OWL-based systems, the RDF object at the base URI of the document
 is an OWL Ontology.

 In Higgins, which uses OWL, the object at the base URI is an OWL
 Ontology that 'imports' the Higgins Ontology.  The RDF file for
 an attribute contains an OWL Class for the attribute named by a
 fragment,e.g., #Firstname, and several related OWL properties and
 RDF instances in that same file that add structure to that class.

 2. In our 'schemat' implementations which attempt to generate RDF for
 existing schemas of 'legacy'/'installed base' protocols, it is  
 desirable to
 be able to have additional, named OWL classes, RDF objects, and other
 modelling and descriptive data definitions that are shared across
 multiple attributes of a single schema. For example, a schema may
 define its own value syntax and matching rules, and wish to share
 those syntaxes and matching rules across the attributes of that  
 schema.
 It would be desirable if there could be a single RDF file which  
 contains
 the attribute type metadata, the syntax definition and matching rule
 definition, rather than needing to have the attribute type metadata
 in a set of files that are separate from the syntax definitions and
 matching rule definitions, or are duplicated in those files.

 3. I find that in our implementation 'schemat' of identity metaschema
 attribute metadata retrieval that is a definite performance gain if
 all the schema elements for a particular schema can be retrieved in
 a single HTTP GET.  It is likely that an implementation interested
 in an attribute Firstname of a particular schema would also be
 seeing a few other attributes Lastname, Middlename etc of the same
 schema, and it would be good if a GET that retrieves the data for
 Firstname also gives the implementation the rest of the schema so
 that it does not need to keep going back and GETing for each
 attribute type.

 4. Requiring that each be in a separate document would likely lead to
 duplication of metadata, particularly Dublin Core metadata that
 describes the schema as a whole.  I feel it would be better if the
 RDF object at the base URI has the Dublin Core metadata for the
 schema as a whole, and that the Attribute Type Metadata is a class
 named by a fragment below that base URI.

 5. (appeal to authority) http://www.w3.org/DesignIssues/Fragment.html
 This means that 

RE: Updated normalization section to match the upcoming XRI Syntax2.1.

2007-04-04 Thread Drummond Reed

Kevin Turner wrote:

Sorry it took me a few months to notice this, but xri://$dns?  No.  I'm
referring here to spec rev 274, the diff for which is attached.  Can we
roll that patch back, please?

I'm not even sure where you're getting an XRI Syntax 2.1 reference from,
there's not so much as a working draft of it published on the technical
committee's page at OASIS.

Thanks,

 =keturn

Kevin,

At the time David and I discussed that change I thought the first XRI Syntax
2.1 WD would be published shortly. Now it's clear it won't be out until
after the f2f meeting of the XRI TC at the OASIS Symposium week after next.

I agree it should not be in there until XRI Syntax 2.1 goes into public
review, which is likely to be late May or early June.

BTW, in the stage before Working Drafts, the TC publishes issues/proposals
on its wiki. You can see the full index of issues/proposals for XRI Syntax
2.1, XRI Resolution 2.0 Working Draft 11, and XRI $ Dictionary 2.0 on the TC
wiki home page at:

http://wiki.oasis-open.org/xri

The $dns syntax is covered on two pages:

http://wiki.oasis-open.org/xri/XriCd02/DictionaryStructure is the
listing of XRI $ Dictionary entries.

http://wiki.oasis-open.org/xri/XriCd02/GlobalXrefs has the proposed
$dns, $ip, and $(http://*) and $(https://*) resolution rules.

We'd love to get feedback from you or anyone in the OpenID community if you
have time to look them over. OTOH, I fully understand if you want to wait
until the Working Drafts are out. I'll be sure to send a notice to the list.

=Drummond

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


RE: Moving AX Forward (WAS RE: SREG namespace URI rollback)

2007-04-04 Thread Drummond Reed
+1 to defining attribute identifier URIs/XRIs in the Identity Commons ID
Schemas project.

=Drummond 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Recordon, David
Sent: Wednesday, April 04, 2007 1:16 PM
To: Johnny Bufu
Cc: OpenID specs list
Subject: RE: Moving AX Forward (WAS RE: SREG namespace URI rollback)

Johnny,
I see a lot of, at least my initial confusion, coming from there being
multiple documents.  This is why I urge merging the transport and
metadata since the reality is they currently are only being used with
each other.  As the metadata document doesn't actually define a new
format, rather references existing formats, I am unsure why it cannot
just be a section in the transport document.  It is understood that you
must use the metadata format for the schema URLs in the transport, so
the two documents really are coupled to begin with.

I agree that you need to bootstrap a set of attributes for people using
AX.  As I have done so in the past, I'd encourage this work happen
within the ID Schemas project (http://idschemas.idcommons.net/) versus
defining First Name yet again for openid.net.  I have no problem with
the spec listing a set of schema URLs, I just strongly feel that
anything non-OpenID specific should be hosted and defined elsewhere
since so many people have already done it.  I do understand the need for
the schema URL hosting the metadata document, which is why I am
advocating this work be done as part of the ID Schemas project to
provide this flexibility.

--David

-Original Message-
From: Johnny Bufu [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, April 04, 2007 12:39 PM
To: Recordon, David
Cc: Dick Hardt; OpenID specs list
Subject: Re: Moving AX Forward (WAS RE: SREG namespace URI rollback)


On 4-Apr-07, at 12:18 PM, Recordon, David wrote:
 One thing that I do think would be worthwhile in smoothing more of 
 this SREG/AX confusion would be adding SREG support to Sxip's OpenID 
 libraries.

This is on the todo list, and judging by the interest showed by some
contributors could happen any day now.

 Any thoughts on spec consolidation

 I think I'd propose the following:
  - Remove http://openid.net/specs/openid-attribute-
 types-1_0-02.html (I
 do not believe OpenID should define its own schema elements for things

 like First Name which are not specific to OpenID, defining a URL for

 an OpenID enabled URL for example I think would be fine on OpenID.net)

I understand that point of view and we were looking into determining
what would be the best place where this spec could live.

However, since the AX's adoption will depend (at least in the beginning,
before the metadata and automatic acquisition mechanisms are finalized)
on the participants using the same names for the attributes they
transfer. From this point of view, I believe AX could use openid.net's
recommendation (if endorsement is too much) to use a set of names / URIs
for the most commonly transfered attributes.  
(Kind of like what made SREG successful -- having the spec provide /
something/ for a jump-start).

  - Merge http://openid.net/specs/identity-attribute-
 metadata-1_0-01.html
 into http://openid.net/specs/openid-attribute-exchange-1_0-04.html.

I don't think we should merge the AX core with the metadata description
document. The first one describes the transport layer  
for attributes and is reasonably close to a final v1, while the metadata
is far from being final (no concrete options identified that would drive
to consensus) and its progress is rather slow.

 and seperating policy from technology?

Not sure what you mean by this.


Johnny

___
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: Modularizing Auth 2.0 Discovery

2007-02-28 Thread Drummond Reed
I've always been supportive of breaking out OpenID Discovery into a separate
spec. I wouldn't break it out into separate specs, however, because
discovery for any OpenID identifier has have much more in common than they
have different. For example, they all need to explain the relationship of
the identifier being resolve to an XRDS document and the metadata needed to
access other OpenID services.

So I'm make the OpenID Discovery spec modular rather than breaking it out
into separate specs.

It also very nicely fits the OpenID layer model, i.e., one specification
(one might argue the foundational spec) for OpenID Discovery -- the layer
that maps an OpenID identifier to the metadata needed to access an OpenID
service -- followed by a specification for OpenID Authentication, and then
other specs from there.

In fact, I'm excited enough about this approach that I'll volunteer to be
one of the editors for OpenID Discovery. I can specifically handle
coordination between the OpenID Discovery spec and the XRDS definitions in
the XRI Resolution spec at OASIS.

=Drummond 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Recordon, David
Sent: Wednesday, February 28, 2007 11:26 AM
To: Martin Atkins; specs@openid.net
Subject: RE: Modularizing Auth 2.0 Discovery

+1, I'm fully in support of this and actually have been wanting to do so
for quite a number of weeks now!

--David 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Martin Atkins
Sent: Wednesday, February 28, 2007 10:44 AM
To: specs@openid.net
Subject: Modularizing Auth 2.0 Discovery


Recently there has been talk about using alternative identifiers for
OpenID, such as email addresses and Jabber Identifiers. This has made it
obvious that the OpenID Authentication protocol doesn't care in the
slightest what the identifier is as long as service discovery can be
performed on it somehow.

Currently the Authentication 2.0 specification has language in various
places that constrains it to URIs with the schemes http, https and xri. 
For example, under Terminology the following definition is given for
Identifier:

 An Identifier is either a http or https URI, (commonly referred
 to as a URL within this document), or an XRI [XRI_Syntax_2.0].
 This document defines various kinds of Identifiers, designed for
 use in different contexts.

My proposal is that we make the core Auth 2.0 spec scheme-agnostic. It
would just state that an identifier is a URI. Later in the spec, where
currently it enumerates a bunch of ways to do discovery, it'd just say
do discovery on the URI using an appropriate protocol. (or, indeed,
words to that effect.) It would also nominate a standard XRDS service
type URI to use during Yadis discovery.

Then we'd publish in parallel the following two ancillary
specifications:
 * OpenID Discovery for HTTP and HTTPS URIs
 * OpenID Discovery for XRI URIs.

Later, the OpenID community or a third party could publish a
specification OpenID Discovery for Email Addresses, but I don't think
we're really ready to go there right now.

The discovery protocols don't necessarily need to be XRDS-based, but if
they are they would presumably reference the standard service type URI
from the Auth spec so that future Auth versions can change this without
needing to re-publish the discovery specs.

This has the following benefits:

   * It gives others a clear, spec-approved mechanism to bolt-on support
for additional URI schemes.

   * It allows the Authentication specification to evolve separately
from the various discovery specifications, which are unlikely to need to
change very much from version-to-version.

   * It formalizes the separation between discovery and authentication,
giving library authors a clear plug-in point if they wish to support
modular discovery.

Presumably the OpenID Auth 2.0 spec would still retain a reference to
the HTTP and HTTPS discovery spec purely so that it can say that RPs
MUST support it regardless of what else they support.

-

All ancillary discovery specifications must, at minimum, define:

   * A pattern for recognizing and canonicalizing their own identifiers.

(For example, the XRI one would include a provision for checking for an
identifier which starts with a global context symbol, etc.)

   * A mechanism for returning the following information:
 - Either: (traditional identity case)
 * Canonical Claimed identifier (an i-number, for example)
 * User-supplied Display identifier (an i-name, for example)
 * OP endpoint URL
 * OP-local identifier (i.e. openid:Delegate as was)
 - Or: (directed identity case)
 * OP endpoint URL
 * Canonical OP identifier (for use in confirmation messages)

(And, of course, not all discovery mechanisms would necessarily support
directed identity.)


___
specs 

RE: Modularizing Auth 2.0 Discovery

2007-02-28 Thread Drummond Reed

Martin Atkins wrote:
 My proposal is that we make the core Auth 2.0 spec scheme-agnostic. It 
 would just state that an identifier is a URI. Later in the spec, where 
 currently it enumerates a bunch of ways to do discovery, it'd just say 
 do discovery on the URI using an appropriate protocol. (or, indeed, 
 words to that effect.) It would also nominate a standard XRDS service 
 type URI to use during Yadis discovery.

If OpenID Discovery is a single, separate, referencable spec, then it
doesn't even have to do that. OpenID Authentication 2.0 can just say
something like:

OpenID is an open, extensible framework for associated identity services
with an identifier. Discovery of the metadata necessary for an OpenID
consuming application to access those services is specified by the OpenID
Discovery specification [reference here].

+1

Rob wrote:
can we also use the opportunity to put i-names support in an extension?

Under this approach, discovery all identifiers (URLs, XRI i-names/i-numbers,
email addresses, phone numbers, etc.) would be handled by OpenID Discovery.

=Drummond 

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


RE: Modularizing Auth 2.0 Discovery

2007-02-28 Thread Drummond Reed

Martin Atkins wrote:

Attached is a version of the current spec draft 11 with large chunks of 
the discovery/normalization stuff hacked out and replaced with generic 
see other specifications text.

I think I may have deleted too much in that we've lost the detailed 
rules for dealing with XRDS documents, which are probably going to be 
referenced by most discovery specs and deserve to be in the core spec. 
See the TODO: markers for more info.

However, in doing this it also occured to me that it would be very 
useful to have the XRDS-related bits of the XRI resolution spec in a 
separate document that we could reference, since our new 
protocol-agnostic core Auth 2.0 spec has no need for the rest of XRI 
resolution. I wonder if the XRI guys would consider making Chapter 3 of 
the XRI Resolution 2.0 spec into a separate document that OpenID Auth 
could reference directly?

The XRI Technical Committee has been working with the OpenID community for
the last year to make sure the XRI Resolution spec is cleanly modular so
that independent pieces of it can be referenced as needed by other specs.
Yadis already does that. Given the extra overhead each spec carries at a SDO
like OASIS, it would be much easier for OpenID Discovery to reference just
the parts of XRI Resolution that it needs. 

But I suggest we close on the best approach for OpenID Discovery first. I'll
answer a different question you posed about that next.

=Drummond 

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


RE: Modularizing Auth 2.0 Discovery

2007-02-28 Thread Drummond Reed

Drummond Reed wrote:
 
 Under this approach, discovery all identifiers (URLs, XRI
i-names/i-numbers,
 email addresses, phone numbers, etc.) would be handled by OpenID
Discovery.
 

Martin Atkins wrote:

I disagree that a single spec can contain discovery rules for all 
conceivable discovery types without becoming ridiculously big. The 
discovery rules in the current spec for just handling HTTP/HTTPS and XRI 
discovery are already big enough.

I'm not proposing a single spec for all discovery rules for all types of
identifiers forever. I am proposing a spec that:

1) Sets out the general framework and requirements for OpenID Discovery
because there is a lot that discovery for any identifier will have in common
(for example, the general rules around XRDS usage).

2) Include sections for the specific identifier types that are already
well-known and implemented -- URLs and XRIs.

3) Specifies how it extensions can be written for other identifiers, such as
email addresses, phone numbers, SIP endpoints, etc.

However, I clearly have a bias for lots of small specs over one large 
spec, and clearly your bias is the opposite. :)

Why do you say that? I've been doing specs for a decade now both inside and
outside of SDOs, and I don't think anyone I've ever worked with would say,
Drummond likes great big bulky specifications. In fact, they would tell
you I absolutely hate them. David and I did a joint paper/presentation on
OpenID at the last's fall ACM conference and we specifically touted OpenID's
modular lightweight specification approach.

But more than anything I'm a big believe Einstein's as simple as possible
but no simpler. In this case, I believe the OpenID framework should have a
clear, cohesive discovery layer, and to do that, it should be anchored in an
OpenID Discovery spec.

=Drummond 

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


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

2007-02-10 Thread Drummond Reed
David,

Great wiki page -- this is the kind of resource that really helps work
through issues like this.

On the issue itself, I need more time to think it through.

=Drummond 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of David Fuelling
Sent: Saturday, February 10, 2007 12: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] FW: PROPOSAL: An Extension to transform an EMail Addressto an OpenId URL

2007-02-10 Thread Drummond Reed

 -Original Message-
 From: Robert Yates [mailto:[EMAIL PROTECTED]

 2) Why map the e-mail address to an openid url, which then has to be
 further resolved to a Yadis document?  Why not, instead, map straight
 to a yadis doc and make e-mails full fledged openids.  An openid is
 nothing more than a URI that can be resolved to a Yadis doc.
 mailto:[EMAIL PROTECTED] is a perfectly valid URI and you have
 demonstrated a pretty simple way to map it to a yadis doc.

This is definitely worth considering.  As you know, the extension I have
proposed is highly controversial.  Past objections (i.e., arguments in
favor
of *not* using an email in lieu of an OpenId) are numerous -- see my wiki
compilation for more details there [1].

[1] http://openid.net/wiki/index.php?title=Debating_Emails_as_OpenIds

 David Fuelling wrote:

To be fair, some of these objections are quite valid, which is why I
decided
to propose a mapping from Email Address to URL, as opposed to making
Email
Addresses a first class citizen of OpenId.

Chief among these is that it would be nice if this extension could be used
in systems outside of OpenId.  Mainly, Yadis is required to map an email
address to a URL per my extension.

In addition, URL-centric identity is something that I consider to be very
cool and very important -- it's a key piece of Identity 2.0, and not
something I want to abandon.  Thus, I decided to create a mapping
proposal, rather than simply something that says, Openid should embrace
email addresses. 

THIS is because (If I understand things correctly) email-addresses can be
normalized to URI's (mailto:[EMAIL PROTECTED]) in a standard fashion, but
that's not the same thing as a URL (URL's are URI's, but not vice-versa).

Thus, without some kind of mapping to URL, it would probably be unwise to
utilize email addresses as OpenIds.

All that said, you are correct that my mapping proposal does present a way
to get a URL from an email address, so maybe I am just adding an
(unnecessary) extra Yadis call into the mix.  However, I still think that
an
extension which makes Email Addresses into OpenId Identifiers would *feel*
different from the extension I proposed, which simply maps an email to a
valid OpenId URL.

It's a subtle difference, and one that I think has often been misunderstood
on the mailing lists.  One is a mapping, which says you can use an email
address at an RP.  The other, which just doesn't feel right to me, says
that an email *IS* your Identity Identifier, which is tough to swallow.

In reality, I'm not sure if this is just something I *feel*, or if there is
a legitimate technical difference between the two.  I think that they are
technically the same, but the latter notion implies something
philosophically about Identity 2.0 that perhaps should not be implied.

I'd appreciate more feedback from the community on this point before I
could
endorse making Emails first-class OpenId citizens (although my proposal
essentially does this via mapping sleight of hand).

What do you think?

David, I think your analysis is right on the mark. It is a very subtle
difference, but in my view extremely important.

Why? IMHO, the foundation of OpenID is resolvable identity endpoints --
endpoints on the Internet that represent what the Identity Gang lexicon
calls digital subjects (http://cis-berkman.editme.com/DigitalSubject).
Note that while digital subjects includes users, they can also include other
resources like organizations, applications, etc.

While it's true that all URIs can be used to identify digital subjects, the
OpenID framework works with that subset of URIs that are *resolvable* (see a
long blog post I did on that subject last year -
http://www.equalsdrummond.name/?p=70). Resolvability is a vital
characteristic of OpenID identifiers (URLs or XRIs) because that's how you
can get to the metadata needed to provide identity services (authentication,
authorization, attribute exchange, messaging, etc.) within the OpenID
framework.

Although an RFC 2822 email address can be cast as a URI using the mailto:
scheme, it's not a resolvable identifier by itself -- only the domain name
portion is resolvable. Your (excellent) ETT spec provides a mapping from an
RFC 2822 email address (or mailto: URI? -- I didn't see if that was included
in the spec, but it's a trivial addition) to a URL which is resolvable.

Therefore I would frame it this way: an email address should be considered
an attribute of a resolvable OpenID identifier (i.e., a URL or XRI), and
your ETT spec should be considered a mechanism for mapping backwards from
the attribute to the resolvable OpenID identifier.

I guess that makes email addresses second class citizens vs. URLs or XRIs
as first class citizens in the OpenID framework, but for good reason.

=Drummond 

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


RE: [OpenID] Dumb Question: Why isn't http://xri.net/=bobwyman an OpenID?

2007-01-04 Thread Drummond Reed
Bob, 

 

From the report you show, the Yadis diagnostic is doing the correct
resolution call to the xri.net HXRI proxy resolver. So it's sites that have
the pre-Yadis RP libraries that won't yet work with HXRIs (or with any other
Yadis-enable URL for that matter). Those libraries are only looking for the
HTML link elements (I think).

 

And I completely agree that an XRI in any format - raw i-name, with an
xri:// scheme prefix, or with an HXRIs proxy resolver prefix like
http://xri.net http://xri.net/  - all need to be interchangeable. You're
right that this will require a slight fix at the i-brokers.

 

=Drummond 

 

  _  

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bob Wyman
Sent: Wednesday, January 03, 2007 11:38 PM
To: Drummond Reed
Cc: Recordon, David; openid-general; specs@openid.net
Subject: Re: [OpenID] Dumb Question: Why isn't http://xri.net/=bobwyman an
OpenID?

 

Drummond,

Thanks for the detailed response. BTW: Below, you'll see what is happening
when I use the Yadis diagnostic on the HXRI. I believe that users will, in
fact, expect XRI's, i-names, and HXRI's to be interchangeable. I'm using
2idi.com, so I guess I have to wait for them to put in the fix?

 

Also, I find it a bit odd that the Yadis diagnostic reports a pass for
OpenID... Apparently, the metric for passing is pretty forgiving.

 

bob wyman

 

http://www.openidenabled.com/resources/yadis-test/yadis-detect?url=http%3A%2
F%2Fxri.net%2F%3Dbobwyman
http://www.openidenabled.com/resources/yadis-test/yadis-detect?url=http%3A%
2F%2Fxri.net%2F%3Dbobwymannegotiation=on negotiation=on 

 

Results for http://xri.net/=bobwyman:

*   I fetched http://xri.net/=bobwyman, asking for content type
application/xrds+xml 
*   The document's content type is application/xrds+xml;trust=none. That
is the XRDS content type. 
*   There was no YADIS HTTP header. 
*   I got a document. It is 916 bytes long and begins '?xml
version=1.0 encoding=UTF-8?\nXRDS ref=xri://=bobwyman x' 
*   I parsed an XRDS document. 
*   I found a service, but it's not a type I recognize. It's a service
at http://2idi.com/contact/ 
*   I found a service, but it's not a type I recognize. It's a
xri://+i-service*(+contact)*($v*1.0) service at http://2idi.com/contact/ 
*   I found a service: OpenID at https://2idi.com/openid/ with delegate
None 
*   I found a service: OpenID at http://2idi.com/openid/ with delegate
None 

*   XRDS: Passed Your YADIS URL leads to an XRDS document. Your YADIS
URL is http://xri.net/=bobwyman 
*   OpenID: Passed Your YADIS URL leads to at least one OpenID service. 


 

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


RE: [OpenID] Dumb Question: Why isn't http://xri.net/=bobwyman an OpenID?

2007-01-04 Thread Drummond Reed
You're right, David -- the only real effect in the spec should be that an
HXRI is recognized as being an XRI (and not a URL) from the standpoint of
what the RP should do once it gets back the XRDS document, i.e., the RP MUST
use the CanonicalID i-number and not the original HXRI.

That would solve the issue Johnny brought up, and also properly support the
use of multiple i-name (or HXRI) synonyms for the same i-number.

=Drummond 

-Original Message-
From: Recordon, David [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, January 03, 2007 11:34 PM
To: Drummond Reed; Bob Wyman; openid-general; specs@openid.net
Subject: RE: [OpenID] Dumb Question: Why isn't http://xri.net/=bobwyman an
OpenID?

 Therefore it seems to me the best thing to do would be to have
 OpenID libraries recognize an HXRI (from the http://xri.* pattern)
 as a form of an XRI, drop the HXRI proxy resolver prefix, and
 proceed with it as an XRI so the user gets the i-name/i-number
 synonym benefits they expect.

I'd agree from a usability standpoint that would be the best
recommendation.  The only thing that would be a bit hard to explain is
that the library could still use http://xri.net as a proxy resolver.  So
the potentially confusing steps would be:
1) User enters http://xri.net/=bobwyman
2) RP sees prefix http://xri.net/=; and then extracts =bobwyman
3) RP constructs Yadis fetch on http://xri.net/=bobwyman for proxy
resolution of the i-name =bobwyman

--David

-Original Message-
From: Drummond Reed [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, January 03, 2007 11:26 PM
To: Recordon, David; 'Bob Wyman'; 'openid-general'; specs@openid.net
Subject: RE: [OpenID] Dumb Question: Why isn't http://xri.net/=bobwyman
an OpenID?

Bob, it's a great question, and David's correct as far as he goes, and
so is Johnny. However I suspect that the behaviour you're experiencing
is due to older OpenID libraries being used by the RP site at which
you're experiencing this behaviour.

Here's why: if you entered your i-name =bobwyman in URL format (we call
this an HXRI -- HTTP XRI) as http://xri.net/=bobwyman, then Johnny is
correct that by both the 1.1 and (pending) 2.0 specs, this would be
considered a URL, and Yadis resolution should proceed on the URL.

However Yadis resolution means the RP library should first do an HTTP
GET on the URL with a content type of application/xrds+xml. Such a
request to an XRI proxy resolution server (which is what http://xri.net
is functioning as) should return you the XRDS document for the XRI
=bobwyman, exactly as Yadis would for any other URL that has its own
XRDS document.

In which case everything should work fine (except the issue of
http://xri.net/=bobwyman now being the Claimed Identifier, see below).
Because that's not happening, the RP library at the site you're testing
must not be doing Yadis resolution, or at least not requesting an XRDS
document type first. Instead it's just doing a plain http GET with no
content type, in which case the HXRI proxy resolver is returning a
redirect to the default service endpoint in the XRDS document per the
XRI Resolution spec.

Since for most i-names, the default service endpoint is the registrant's
contact page, at least one i-broker, 1id.com, has cleverly got around
this non-Yadis-compliant behaviour by adding the necessary OpenID link
elements to the HTML of the contact page. (Victor Grey at 2idi told me
today that he plans to implement the same workaround.)

While this is a smart workaround, it shouldn't be necessary if the
library just does Yadis resolution in the correct order on the HXRI.

However all of this still leaves the open issue that Johnny raised,
namely that the current draft OpenID Authentication 2.0 spec treats
=bobwyman and http://xri.net/=bobwyman as separate identifiers.
Ironically, in XRI Syntax
2.1 the XRI TC is formalizing HXRI syntax (it was originally part of XRI
Resolution 2.0 Working Draft 10, but we need to make it a formal part of
XRI Syntax), and we are making it very explicit that from the standpoint
of equivalence, the proxy resolver prefix of any HXRI is NOT part of the
XRI.
In other words, the following two identifier...

http://xri.net/=bobwyman
=bobwyman

...are equivalent XRIs because the former is really just the HXRI proxy
resolver prefix http://xri.net; plus the absolute XRI =bobwyman.

Therefore it seems to me the best thing to do would be to have OpenID
libraries recognize an HXRI (from the http://xri.* pattern) as a form of
an XRI, drop the HXRI proxy resolver prefix, and proceed with it as an
XRI so the user gets the i-name/i-number synonym benefits they expect.

Johnny, David, Josh: do you agree?

=Drummond 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Recordon, David
Sent: Wednesday, January 03, 2007 8:55 PM
To: Bob Wyman; openid-general; specs@openid.net
Subject: Re: [OpenID] Dumb Question: Why isn't
http://xri.net/=bobwymananOpenID?

My guess is that when

RE: Key Discovery In DTP Draft 3

2007-01-04 Thread Drummond Reed
Just FYI, the xmldsig KeyInfo element is already part of the XRD schema
because the XRI Resolution spec uses it in the SAML form of trusted XRI
resolution. And either the SAML form or the HTTPS form of XRI trusted res
can give you the security characteristics in the Key Discovery spec.

That said, there can be advantages to managing the cert via an independent
service.

So I'm not coming down on either side (yet ;-)

=Drummond 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Recordon, David
Sent: Thursday, January 04, 2007 10:07 PM
To: Carl Howells; Grant Monroe
Cc: specs@openid.net
Subject: Key Discovery In DTP Draft 3

Hey guys,
Was looking at
http://openid.net/specs/openid-service-key-discovery-1_0-01.html tonight
and curious why the decision was made to define the PublicKey /
element which contains a link to the RSA key or X.509 certificate versus
embedding the key in the XRDS file?

From the research I've done tonight, it looks like the W3C in 2002
described how to do this as part of xmldsig.  Seems like we can just use
the KeyInfo element.
http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/#sec-KeyInfo
They've also then recently put out a note describing the changes to that
document to match XML in 2006.
http://www.w3.org/TR/2006/NOTE-DSig-usage-20061220/

Is there something that I'm missing from the design standpoint as to why
this wasn't done?  If anything, it seems like it would reduce a fetch if
the key was in the XRDS file itself.

--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: Key Discovery In DTP Draft 3

2007-01-04 Thread Drummond Reed
That could work. Very XDI RDF-like approach, i.e., the URL/XRI being
resolved is the Subject, the URL/XRI value of the Type element is the RDF
predicate, and the value of the data sharing:KeyInfo element is the RDF
object (in this case a literal).

=Drummond 

-Original Message-
From: Recordon, David [mailto:[EMAIL PROTECTED] 
Sent: Thursday, January 04, 2007 10:35 PM
To: Drummond Reed; Carl Howells; Grant Monroe
Cc: specs@openid.net
Subject: RE: Key Discovery In DTP Draft 3

Oooh, interesting...

So looking at working draft 10
http://www.oasis-open.org/committees/download.php/17293 it seems that
3.2.5 is most relevant in that it describes
xrd:XRD/xrd:Service/ds:KeyInfo which seems to be where in the schema the
key would want to sit.  The only thing is that 3.2.5 is talking about
having the key present to verify a signature on the XRD file itself,
though in this case it may not actually be signed.

What I was toying with was something along the lines of:
Service
 
Typehttp://www.w3.org/TR/2002/REC-xmldsig-core-20020212/#sec-KeyInfo/
Type
  ds:KeyInfo
...
  /ds:KeyInfo
/Service

Thus it makes it easy for existing Yadis libraries to pick the key out
by the Type element.

--David

-Original Message-
From: Drummond Reed [mailto:[EMAIL PROTECTED] 
Sent: Thursday, January 04, 2007 10:23 PM
To: Recordon, David; 'Carl Howells'; 'Grant Monroe'
Cc: specs@openid.net
Subject: RE: Key Discovery In DTP Draft 3

Just FYI, the xmldsig KeyInfo element is already part of the XRD schema
because the XRI Resolution spec uses it in the SAML form of trusted XRI
resolution. And either the SAML form or the HTTPS form of XRI trusted
res can give you the security characteristics in the Key Discovery spec.

That said, there can be advantages to managing the cert via an
independent service.

So I'm not coming down on either side (yet ;-)

=Drummond 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Recordon, David
Sent: Thursday, January 04, 2007 10:07 PM
To: Carl Howells; Grant Monroe
Cc: specs@openid.net
Subject: Key Discovery In DTP Draft 3

Hey guys,
Was looking at
http://openid.net/specs/openid-service-key-discovery-1_0-01.html tonight
and curious why the decision was made to define the PublicKey /
element which contains a link to the RSA key or X.509 certificate versus
embedding the key in the XRDS file?

From the research I've done tonight, it looks like the W3C in 2002
described how to do this as part of xmldsig.  Seems like we can just use
the KeyInfo element.
http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/#sec-KeyInfo
They've also then recently put out a note describing the changes to that
document to match XML in 2006.
http://www.w3.org/TR/2006/NOTE-DSig-usage-20061220/

Is there something that I'm missing from the design standpoint as to why
this wasn't done?  If anything, it seems like it would reduce a fetch if
the key was in the XRDS file itself.

--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] Dumb Question: Why isn't http://xri.net/=bobwyman an OpenID?

2007-01-03 Thread Drummond Reed
Bob, it's a great question, and David's correct as far as he goes, and so is
Johnny. However I suspect that the behaviour you're experiencing is due to
older OpenID libraries being used by the RP site at which you're
experiencing this behaviour.

Here's why: if you entered your i-name =bobwyman in URL format (we call this
an HXRI -- HTTP XRI) as http://xri.net/=bobwyman, then Johnny is correct
that by both the 1.1 and (pending) 2.0 specs, this would be considered a
URL, and Yadis resolution should proceed on the URL.

However Yadis resolution means the RP library should first do an HTTP GET on
the URL with a content type of application/xrds+xml. Such a request to an
XRI proxy resolution server (which is what http://xri.net is functioning as)
should return you the XRDS document for the XRI =bobwyman, exactly as Yadis
would for any other URL that has its own XRDS document.

In which case everything should work fine (except the issue of
http://xri.net/=bobwyman now being the Claimed Identifier, see below).
Because that's not happening, the RP library at the site you're testing must
not be doing Yadis resolution, or at least not requesting an XRDS document
type first. Instead it's just doing a plain http GET with no content type,
in which case the HXRI proxy resolver is returning a redirect to the default
service endpoint in the XRDS document per the XRI Resolution spec.

Since for most i-names, the default service endpoint is the registrant's
contact page, at least one i-broker, 1id.com, has cleverly got around this
non-Yadis-compliant behaviour by adding the necessary OpenID link elements
to the HTML of the contact page. (Victor Grey at 2idi told me today that he
plans to implement the same workaround.)

While this is a smart workaround, it shouldn't be necessary if the library
just does Yadis resolution in the correct order on the HXRI.

However all of this still leaves the open issue that Johnny raised, namely
that the current draft OpenID Authentication 2.0 spec treats =bobwyman and
http://xri.net/=bobwyman as separate identifiers. Ironically, in XRI Syntax
2.1 the XRI TC is formalizing HXRI syntax (it was originally part of XRI
Resolution 2.0 Working Draft 10, but we need to make it a formal part of XRI
Syntax), and we are making it very explicit that from the standpoint of
equivalence, the proxy resolver prefix of any HXRI is NOT part of the XRI.
In other words, the following two identifier...

http://xri.net/=bobwyman
=bobwyman

...are equivalent XRIs because the former is really just the HXRI proxy
resolver prefix http://xri.net; plus the absolute XRI =bobwyman.

Therefore it seems to me the best thing to do would be to have OpenID
libraries recognize an HXRI (from the http://xri.* pattern) as a form of an
XRI, drop the HXRI proxy resolver prefix, and proceed with it as an XRI so
the user gets the i-name/i-number synonym benefits they expect.

Johnny, David, Josh: do you agree?

=Drummond 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Recordon, David
Sent: Wednesday, January 03, 2007 8:55 PM
To: Bob Wyman; openid-general; specs@openid.net
Subject: Re: [OpenID] Dumb Question: Why isn't
http://xri.net/=bobwymananOpenID?

My guess is that when a normal HTTP fetch is performed against
http://xri.net/=bobwyman, the proxy resolver expects you to be in a
browser and thus issues a 302 Redirect to your contact page.

One option is if the iBrokers (is it iBroker or i-broker?) included
Yadis on each contact page.  This would mean the OpenID Relying Party
would fetch http://xri.net/=bobwyman, be redirected to
http://2idi.com/contact/=bobwyman, and then have that URL to perform
discovery.  The problem this presents is that the Relying Party follows
redirects and canonicalizes the final URL as the Claimed Identifier.
This thus means you'd no longer be making a claim about
http://xri.net/=bobwyman, but rather that you own
http://2idi.com/contact/=bobwyman.  Thus if you change iBrokers, this
assertion would no longer remain valid.  It also removes the protection
the iNumber (and CanonicalID tag) adds to the XRI Resolution process
since i-names can be reassigned.

I'm unsure if there is some trickery that could be done in the Yadis
discovery document to resolve this, though really what I think would end
up is you would enter http://xri.net/=bobwyman to start the discovery
process, but then end up making an assertion about =bobwyman and not the
URL version of it.

Someone correct me here if my logic is wrong.

--David



From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Bob Wyman
Sent: Wednesday, January 03, 2007 8:44 PM
To: openid-general
Subject: [OpenID] Dumb Question: Why isn't http://xri.net/=bobwyman
anOpenID?


My apologies if this is a really dumb question...
 
Why is it that I can do OpenID authentication with either of =bobwyman
or xri://=bobwyman but, according to the OpenIDEnabled checkup

RE: Questions on Protocol

2007-01-02 Thread Drummond Reed
Welcome, James. I have a special interest in this topic due to my work on
XDI (XRI Data Interchange) at OASIS. I'm happy to help figure out how it can
be applied here.

+1 to Dick's suggestion to just keep the posts modular, i.e., short on-topic
threads that can be discussed individually.

=Drummond 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Dick Hardt
Sent: Tuesday, January 02, 2007 1:06 PM
To: McGovern, James F (HTSC, IT)
Cc: specs@openid.net
Subject: Re: Questions on Protocol

Hi James

These look like good discussion topics for the specs list. A separate  
post clarifying each notion would be a great starting point.

-- Dick

On 2-Jan-07, at 8:57 AM, McGovern, James F ((HTSC, IT)) wrote:

 Johannes invited me to lead the development of the specification  
 for including relationships and authorization as part of OpenID. I  
 have the following questions:

 1. Would it be too distracting to have the conversation occur on  
 this listserv or should the admin establish another one?

 2. I would also like to get a dialog going around how OpenID would  
 need to work in order to support notions such as Identity  
 propagation, integration into BPM and ECM platforms and support for  
 Identity Based Encryption



 ** 
 ***
 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: [OpenID] OpenID Assertion Quality Extension - Draft

2006-11-30 Thread Drummond Reed
Avery,

 

Paul's the one to weigh in on this option - he wrote (and lived) the book on
SAML AuthN Context. But I do like the looks of what you proposed - seems
very elegant.

 

=Drummond 

 

  _  

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Avery Glasser
Sent: Thursday, November 30, 2006 2:22 PM
To: George Fletcher
Cc: specs@openid.net; [EMAIL PROTECTED]
Subject: Re: [OpenID] OpenID Assertion Quality Extension - Draft

 

Just to weigh in here...






Paul Madsen wrote: 

Hi George, for your use case below, why would not the RP just ask for the
user to be up-authenticated at the desired higher level when necessary? 

So in the draft... how does the RP ask for the user to be
up-authenticated? The authentication request parameters do not in any way
indicate a previous authentication, and the extension parameters also don't
include any way to indicate a previous authentication. That is what I really
meant by the authentications being standalone. The RP may relate the two
authentications in some way because it requested both. Maybe that's good
enough.

Basically, you would require the second method with a max_age of 0 -
which, assuming the RP honors the request, would tell the RP to
re-authenticate the user with the requested method. 






Are you asking whether the RP should be allowed to ask the user to
re-present their URI in order for this to happen? And thereby effectively
treating each event as disconnected/standalone? 

Ideally, the user would not be able to change their URI when being
re-challenged based on max_auth_age but I guess the RP should make sure to
code for that edge case.

Agreed - it's the RPs choice.






Wrt combinations, I know from experience that the alternative to allowing
for RPs to specify combinations is a combinatorial explosion in the number
of mechanism identifiers. 

I agree that the combinations can explode... but they are also useful. For
example to hack my account you need both my password and my hardotp.
That's two secrets that need to be determined for my account to be
compromised. (Not that this doesn't stop phishers).

 

Actually, this could be pretty simple to implement:

 

Replace openid.aqe.preferred_auth_mode with the following:

 

openid.aqe.auth_factor1

Optional: The method of authentication the RP would like the OP to perform,
or in the case of a multi-factor authentication, the first method that the
RP would like the OP to perform. The mode should match one of the advertised
values in the XRDS. If this is not specified, then any authentication method
is acceptable.

Value: Comma-delimited list of none, password, pin, fingerbio,
handbio, hardotp, irisbio, otherbio, smartcard, softotp,
voicebio

Note: The OP should attempt to authenticate the user with the most secure
mode requested. For example, if the OP has determined that their voicebio
method is stronger than their password method and the RP requests either
voicebio or password, the OP should strive to authenticate the user by
voicebio when possible. If the two modes are considered equally strong,
then it is the choice of the OP regarding which one or ones to authenticate
against. OPs should note that authenticating a user by a non-preferred
method may result in an RP denying access.

openid.aqe.auth_factor2

Optional: In the case of a multi-factor authentication, the second method
that the RP would like the OP to perform. The mode should match one of the
advertised values in the XRDS. If this is not specified, then any
authentication method is acceptable. If this is not specified, it is assumed
that the RP is requesting only a single factor for authentication. The OP
will not use the same method for this factor as was used in any previous
factors. For example, if the first factor is a password, the second factor
cannot also be a password.

Value: Comma-delimited list of none, password, pin, fingerbio,
handbio, hardotp, irisbio, otherbio, smartcard, softotp,
voicebio

Note: The OP should attempt to authenticate the user with the most secure
mode requested. For example, if the OP has determined that their voicebio
method is stronger than their password method and the RP requests either
voicebio or password, the OP should strive to authenticate the user by
voicebio when possible. If the two modes are considered equally strong,
then it is the choice of the OP regarding which one or ones to authenticate
against. OPs should note that authenticating a user by a non-preferred
method may result in an RP denying access.

openid.aqe.auth_factor3

... you can figure how it would continue. There are very few use cases that
would use more than two factors.

 

So, in this case, if you want the user to authenticate with two factors,
first with a password and second with a securID or voice biometric print...

 

openid.aqe.auth_factor1 = password

openid.aqe.auth_factor2 = hardotp, voicebio

 

conversely, if you want two factors, which could 

IdP vs OP (WAS: RE: EditorsConference Call))

2006-11-09 Thread Drummond Reed
John,

Thanks for the clarification. Eve's mail, clarifying the SAML Glossary
definition of identity provider, helped address some of my concerns.
Although I feel that authentication authority is the single most accurate
term for what an OpenID authentication service provider (currently called
either an IdP and proposed to be called an OP) is providing, at this point
I'm willing to go with the sentiments of the rest of the list if they prefer
to either stick with IdP or switch to OP.

=Drummond 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of John Kemp
Sent: Wednesday, November 08, 2006 6:19 PM
Cc: specs@openid.net
Subject: Re: Authentication Authority (was RE: IdP vs OP (WAS: RE:
EditorsConference Call))

Hi Drummond,

If what we're trying to express is merely that an OpenID can provide an
authentication assertion, then I agree that authentication authority
is quite appropriate.

I would note that in SAML at least (as I understand it - correct me if
I'm wrong Eve!), an authentication authority is not (in that role at
least) being requested to actually authenticate the user (ie. to
actually perform the authentication at that moment) - the request is
only asking whether the authority can make an authentication assertion
(ie. it's a query for authentication assertions, rather than an
authentication request - which may have already been fulfilled).

I don't know if that rather subtle difference is of any interest in OpenID?

- John

Drummond Reed wrote:
 Eve,
 
 Welcome, and thanks for delurking ;-)
 
 I'm fascinated by your suggestion that the SAML vocabulary includes the
term
 authentication authority. I'd vote for the OpenID Authentication 2.0
 specification (and the community at large) to adopt that term in a
heartbeat
 because: 
 
 a) I've many times thought that authentication authority was PRECISELY
the
 role that the IdP/OP played in OpenID Authentication.
 
 b) I'm all for consistency with the SAML glossary because I know it was
 intended to be specification-neutral and I'm a big supporter of
harmonizing
 vocabularies in a problem space (that's why we spent so long on the XRI
 glossary in the identifier problem space -- see appendix C of
 http://www.oasis-open.org/committees/download.php/15377). 
 
 c) It allows us to step around all the semantic issues around whether an
 OpenID IdP is really providing an identity or not (and also whether
OpenID
 is using classic identity federation or not.)
 
 =Drummond 
 
 -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
 Of Eve L. Maler
 Sent: Tuesday, November 07, 2006 8:16 AM
 To: specs@openid.net
 Subject: Re: IdP vs OP (WAS: RE: Editors Conference Call)
 
 Delurking for the first time on this list: :-)
 
 Drummond and I are on the same page about many things, but John is 
 right that SAML is agnostic as to the strength/significance of the 
 service being provided and so the two cases are much more similar 
 than different.  On balance I prefer identity provider because 
 it's intuitive in an English sense, it's used in several technology 
 contexts (not just SAML and OpenID), and it avoids a terminological 
 branding that would otherwise seem to suggest a conceptual 
 divergence that doesn't -- to my mind -- exist.
 
 (By the way, there's another term SAML defines that seems to fit the 
 bill of what Drummond is going for here: authentication authority. 
   This is not quite synonymous with identity provider in 
 SAML-land, but it's close -- much the way that relying party and 
 service provider are often close to the same thing.  I'm not 
 seriously advocating using it -- just noting that the same software 
 component in an actual deployment can be seen in various lights and 
 have multiple names (roles!).)
 
 FWIW,
 
   Eve
 
 John Kemp wrote:
 Hi Drummond,

 Drummond Reed wrote:
 So why, indeed, is there so much interest in OpenID? I believe it's
 because
 of the trust model. To the best of my knowledge, it is radically
 different
 than the trust model assumed by the majority of use cases which led to
 SAML
 and the Liberty Alliance specs. As Eve Maler of Sun puts it, OpenID
 supports
 promiscuous federation -- RPs and OPs that don't know anything at all
 about each other. 
 At http://www.openidp.org you'll find a promiscuous SAML IdP.

 While I agree with you that OpenID has been focused on this use-case,
 with an eye to the use-cases satisfied by SAML, I'd say that SAML has
 been developed with federated use-cases, but also with an eye to
 promiscuity.

 But to put it another way, the trust model used with SAML is
 out-of-scope for development of the SSO protocol itself.

 Just like it is for OpenID.

 And it doesn't stop there. OpenID also supports OPs that
 ***have zero control over the user's OpenID identifier***. The OP simply
 provides a service for authenticating that a user has control of the
 OpenID
 identifier about which the OP is being queried.
 And how does

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

2006-11-08 Thread Drummond Reed

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Peter Watkins
Sent: Wednesday, November 08, 2006 4:21 PM
To: [EMAIL PROTECTED]
Cc: specs@openid.net
Subject: Re: [PROPOSAL] Handle http://[EMAIL PROTECTED] Style Identifiers

Recordon, David wrote:
 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.

Yes, the TXT proposal seems complex. I prefer Phillip's second
suggestion, but I think something more unique would be advisable, e.g.

http://openid.example.com/openid/user

so that organizations can more easily separate the OpenID IdP systems
(hostname openid.MAILDOMAIN, web path /openid/) from any regular
http/https offerings.

It would be nice (see my 'concerns about each user having a unique
URL' thread in the general openid list) if this could handle empty
usernames, e.g. if users could claim an identifier like
  @example.com
to identify the IdP but let the IdP determine the user's identifier.

Peter, as I mentioned in my reply on the General list, this is how the
directed identity feature in OpenID Authentication 2.0 works. That was
David's original suggestion as I remember -- have OpenID RPs treat an email
address as simply an IdP name and execute the protocol from there.

Since the XRI TC is now working on specifying the email form of an XRI
(called an MXRI -- mailto XRI), this could work for both ordinary email
addresses and MXRI addresses. But that's only if we decide that using an
email address as an OpenID identifier makes sense, or if it just adds a new
layer of confusion (as others have noted).

=Drummond 

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


Authentication Authority (was RE: IdP vs OP (WAS: RE: Editors Conference Call))

2006-11-07 Thread Drummond Reed
Eve,

Welcome, and thanks for delurking ;-)

I'm fascinated by your suggestion that the SAML vocabulary includes the term
authentication authority. I'd vote for the OpenID Authentication 2.0
specification (and the community at large) to adopt that term in a heartbeat
because: 

a) I've many times thought that authentication authority was PRECISELY the
role that the IdP/OP played in OpenID Authentication.

b) I'm all for consistency with the SAML glossary because I know it was
intended to be specification-neutral and I'm a big supporter of harmonizing
vocabularies in a problem space (that's why we spent so long on the XRI
glossary in the identifier problem space -- see appendix C of
http://www.oasis-open.org/committees/download.php/15377). 

c) It allows us to step around all the semantic issues around whether an
OpenID IdP is really providing an identity or not (and also whether OpenID
is using classic identity federation or not.)

=Drummond 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Eve L. Maler
Sent: Tuesday, November 07, 2006 8:16 AM
To: specs@openid.net
Subject: Re: IdP vs OP (WAS: RE: Editors Conference Call)

Delurking for the first time on this list: :-)

Drummond and I are on the same page about many things, but John is 
right that SAML is agnostic as to the strength/significance of the 
service being provided and so the two cases are much more similar 
than different.  On balance I prefer identity provider because 
it's intuitive in an English sense, it's used in several technology 
contexts (not just SAML and OpenID), and it avoids a terminological 
branding that would otherwise seem to suggest a conceptual 
divergence that doesn't -- to my mind -- exist.

(By the way, there's another term SAML defines that seems to fit the 
bill of what Drummond is going for here: authentication authority. 
  This is not quite synonymous with identity provider in 
SAML-land, but it's close -- much the way that relying party and 
service provider are often close to the same thing.  I'm not 
seriously advocating using it -- just noting that the same software 
component in an actual deployment can be seen in various lights and 
have multiple names (roles!).)

FWIW,

Eve

John Kemp wrote:
 Hi Drummond,
 
 Drummond Reed wrote:
 So why, indeed, is there so much interest in OpenID? I believe it's
because
 of the trust model. To the best of my knowledge, it is radically
different
 than the trust model assumed by the majority of use cases which led to
SAML
 and the Liberty Alliance specs. As Eve Maler of Sun puts it, OpenID
supports
 promiscuous federation -- RPs and OPs that don't know anything at all
 about each other. 
 
 At http://www.openidp.org you'll find a promiscuous SAML IdP.
 
 While I agree with you that OpenID has been focused on this use-case,
 with an eye to the use-cases satisfied by SAML, I'd say that SAML has
 been developed with federated use-cases, but also with an eye to
 promiscuity.
 
 But to put it another way, the trust model used with SAML is
 out-of-scope for development of the SSO protocol itself.
 
 Just like it is for OpenID.
 
 And it doesn't stop there. OpenID also supports OPs that
 ***have zero control over the user's OpenID identifier***. The OP simply
 provides a service for authenticating that a user has control of the
OpenID
 identifier about which the OP is being queried.
 
 And how does one authenticate that the user has control over an
 identifier? Is it not by having the OpenID IdP having some secret shared
 with the user - maybe a password, say?
 
 A SAML IdP also authenticates that an identifier (issued by the IdP in
 the SAML case) is bound to a particular user.
 
 This is a big deal. In fact, the closer you get to it, the bigger it is.

 As a result, even though an OP seems to fit the SAML definition of an IdP
--
 and many technical folks will be very comfortable treating the two as
 synonymous -- getting the semantics right to stress who really is in
control
 of the identity ***right down to the identifier*** is very important.

 
 I don't think we need to worry about fitting the SAML glossary
 definition of an IdP, but rather we should focus on making an OpenID
 glossary definition that makes sense for what OpenID is doing.
 
 Whatsmore, I don't think this should or will drive SAML and OpenID
further
 apart. In factit could actually help pave the path to convergence: an OP
 can be defined as being a SAML IdP that provides identifier
authentication
 services using the OpenID protocol, which may end out (3.0?) becoming a
very
 specific set of SAML capabilities.
 
 As noted earlier, I think a SAML IdP also provides identifier
 authentication. I don't worry so much about convergence of these
 technologies (although that would be nice ;), but more about giving a
 converged message to users, developers, and purchasers of these
 technologies.
 
 Regards,
 
 - John
 
 =Drummond 

 -Original Message-
 From: [EMAIL

RE: OpenID.net Service Type Namespaces

2006-11-07 Thread Drummond Reed
My understanding is that the concern is with potential conflicts in the
actual functioning of openid.net.

Creating a clean DNS namespace for specs at specs.openid.net does seem like
a good solution to me.

=Drummond 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Dick Hardt
Sent: Tuesday, November 07, 2006 8:09 AM
To: Recordon, David
Cc: specs@openid.net
Subject: Re: OpenID.net Service Type Namespaces

What is the concern? The argument for keeping it the current way is  
for consistency. The URL resolution does not need to be trusted does it?

On 6-Nov-06, at 5:04 PM, Recordon, David wrote:

 I'm still concerned with using the openid.net/ namespace.   
 Objections
 to using http://specs.openid.net/authentication/2.0/signon?  We don't
 need to change this in legacy stuff, just for 2.0 moving forward.

 --David

 -Original Message-
 From: Dick Hardt [mailto:[EMAIL PROTECTED]
 Sent: Saturday, October 21, 2006 7:34 PM
 To: Granqvist, Hans
 Cc: Recordon, David; specs@openid.net
 Subject: Re: OpenID.net Service Type Namespaces

 I am very supportive of an HTTP GET retrieving the specification.

 I think there are some issues with putting the date in the URL:

 1) the URL is unknown until the spec is completed. Any implementations
 being done during the specification then have a moving target. The URL
 is embedded in the Yadis document and I can see it causing some
 headaches for people that it is not fixed until the end.

 2) the grouping is by time instead of by specification. If I want  
 to see
 all versions of a specification, it is not obvious

 Currently we have:
   http://openid.net/signon/1.0
   http://openid.net/signon/1.1
   http://openid.net/server/2.0
   http://openid.net/signon/2.0
   http://openid.net/identifier_select/2.0

 Given that the 1.x ones are already there, I would recommend we keep
 using that scheme.

 -- Dick

 On 20-Oct-06, at 3:39 PM, Granqvist, Hans wrote:

 It has had some voices against it, but how about considering this
 template (used in for example W3C xmldsig and
 xmlenc):

 http://openid.net/[year]/[month]/[project]#[type]

 Time-dependent (rather than version--dependent) namespaces can evolve
 freely and will not be tied down to specific versioning numbers.

 Example:
 http://openid.net/2006/10/authentication
 http://openid.net/2006/10/authentication#signon


 It's cool if an HTTP GET on these links returns the specification.

 Once a spec is finalized, the then current year/month becomes that
 spec's namespace. For example, xmlenc's namespace is
 http://www.w3.org/2001/04/xmlenc

 Hans


 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] On Behalf Of Recordon, David
 Sent: Friday, October 20, 2006 3:09 PM
 To: specs@openid.net
 Subject: OpenID.net Service Type Namespaces

 Right now we have things like http://openid.net/signon/1.1,
 http://openid.net/sreg/1.0, etc.  This doesn't really seem to scale,
 populating the main http://openid.net namespace.

 Could we do something like
 http://specs.openid.net/authentication/2.0/signon or
 http://specs.openid.net/authentication/2.0/identifier_select
 as well as then http://specs.openid.net/sreg/1.0?

 This would give all the specs their own namespaces, as well as make
 it so we can do smart redirection from each of these type urls to
 the correct anchor in the individual spec.

 --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






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

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


RE: Making return_to Optional

2006-11-06 Thread Drummond Reed
David, in the message below, I assume you meant to say return_to is
NOW an optional parameter... instead of return_to is
NOT an optional parameter That's the only way I can make sense of it.
Am I right?

=Drummond 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Recordon, David
Sent: Monday, November 06, 2006 11:10 AM
To: specs@openid.net
Subject: Making return_to Optional

From the call last week and the proposal at
http://openid.net/pipermail/specs/2006-October/000430.html, return_to is
not an optional parameter in the authentication request.  The idea being
that a RP not sending it signals the IdP to not redirect the user back;
rather an extension will be doing something useful.  I've checked in
this change, though would like it reviewed since I am not completely
happy with all the wording.

http://openid.net/svn/comp.php?repname=specificationspath=compare%5B%5
[EMAIL PROTECTED]compare
[EMAIL PROTECTED]ma
nualorder=1

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: IdP vs OP (WAS: RE: Editors Conference Call)

2006-11-06 Thread Drummond Reed
I want to clear up what I believe are two misconceptions about the proposed
terminology change (both in the specs and across all the OpenID
educational/marketing materials) from Identity Provider (IdP) to OpenID
Provider (OP). (Note that these are my personal views and may not be shared
by others on the list -- the are offered to help propel the discussion
towards a community consensus.)

1) I don't personally believe there is much difference at all between
identity provider (IdP) and OpenID provider (OP) -- certainly not enough
to debate. We might even just agree that an OP is what SAML calls an IdP
that uses the OpenID protocol for authentication. That's not at all the
reason why I support the terminology change. The real reason...

2) ...is that in the context of user-centric identity, I have always felt
that the term identity provider -- though I fully understand that it goes
back to the start of SAML -- is at least inappropriate and perhaps even
downright misleading.

Why? It's because in a user-centric identity, the OP is fundamentally
NOT (that enough stars for you? ;-) the provider of anyone's
identity.

This might look like a little thing, but on such little things entire
worldviews rest. 

Let me elaborate. In the last 2 months, I've had numerous conversations with
SAML proponents asking me, Why is there so much interest in OpenID? It's
just reinventing SAML without a lot of the complexity. And each time I
admit that, to the best of my knowledge, this is largely true.

So why, indeed, is there so much interest in OpenID? I believe it's because
of the trust model. To the best of my knowledge, it is radically different
than the trust model assumed by the majority of use cases which led to SAML
and the Liberty Alliance specs. As Eve Maler of Sun puts it, OpenID supports
promiscuous federation -- RPs and OPs that don't know anything at all
about each other. And it doesn't stop there. OpenID also supports OPs that
***have zero control over the user's OpenID identifier***. The OP simply
provides a service for authenticating that a user has control of the OpenID
identifier about which the OP is being queried.

This is a big deal. In fact, the closer you get to it, the bigger it is.

As a result, even though an OP seems to fit the SAML definition of an IdP --
and many technical folks will be very comfortable treating the two as
synonymous -- getting the semantics right to stress who really is in control
of the identity ***right down to the identifier*** is very important.

Whatsmore, I don't think this should or will drive SAML and OpenID further
apart. In factit could actually help pave the path to convergence: an OP
can be defined as being a SAML IdP that provides identifier authentication
services using the OpenID protocol, which may end out (3.0?) becoming a very
specific set of SAML capabilities.

=Drummond 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Recordon, David
Sent: Monday, November 06, 2006 11:46 AM
To: Dick Hardt; John Kemp; Patrick Harding
Cc: specs@openid.net
Subject: IdP vs OP (WAS: RE: Editors Conference Call)

I see both sides of this discussion.  I think John is correct that the
role of an OP really is not that different than that of SAML's IdP.  The
difference comes down to the trust model.  I certainly think reputation
networks will exist which rate OPs, RPs, users, etc and will ultimately
be needed for a technologies with promiscuous trust models to thrive
in a large scale.

I guess reading more of this is making me question if renaming IdP
really is the best thing to do in OpenID.  I think if anything we all,
as a larger community, should be working to bring OpenID and SAML closer
together versus driving them further apart.

--David

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Dick Hardt
Sent: Wednesday, November 01, 2006 2:20 PM
To: John Kemp
Cc: specs@openid.net
Subject: Re: Editors Conference Call


On 1-Nov-06, at 12:28 PM, John Kemp wrote:
 OK. Just checking. So an IdP/OP can choose whether or not to trust a 
 particular RP, based on some out-of-ban criteria. And an RP can choose

 whether or not to trust the assertions of a particular IdP/OP? OK 
 good.

Technically possible, yes for the RP to decide on an IdP/OP.
Currently, there is no verified RP identity, so the IdP/OP cannot make
that decision.

 I have not had a chance to wade into that discussion.

 I'd highly recommend it when you get the chance.

in my queue :)



 I suspect the latter case will be unlikely, if OpenID is to be 
 successful.

 And I do not. And that is the big driver why it should be OP instead 
 of IdP.

 I think what you're trying to say is that OpenID won't depend on 
 static trust relationships (like business contracts) between RPs and 
 IdP/ OPs - is that right? In which case, sure, I get that.

 But I do think OpenID will depend on there emerging a way of some RP 
 trusting (or not) some 

RE: Making identities persistent?

2006-10-31 Thread Drummond Reed








Good answer, George. The question applies
mainly to delegated identifiers (e.g., email addresses delegated under a
specific DNS domain like [EMAIL PROTECTED], third-or-lower level domain names like
user.aol.com, or community i-names such as @aol*user), since they are by
definition assigned within the context of (and thus under the ultimate control
of) as specific identifier community (such as aol.com). 



For identifiers registered directly with a
global registry (e.g., joesmith.com in DNS or =joe.smith in XRI), the identifiers
themselves are portable across registrars and the registrant has direct control
of the identifier and what it resolves to (e.g., the XRDS document).This portability
is established by ICANN for DNS registries and XDI.org for XRI global
registries.



So the section of the spec you cite should
probably be clarified with regard to these points, i.e., something like: 



OpenID is decentralized. No central authority must approve or register Relying Parties or OpenID Providers. An End User can freely choose which OpenID Provider to use. OpenID design also enables an End User to continue to use an OpenID Identifier if they switch OpenID Providers. Note that the portability and persistence of an OpenID identifier itself (URL or XRI) is a capability of the identifier and the registry authority and is out of scope for OpenID. End Users who wish to maintain persistent control of an OpenID Identifier SHOULD select an identifier and registry authority that offers these capabilities.



Thoughts?



=Drummond 









From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of George Fletcher
Sent: Tuesday, October 31, 2006
7:36 AM
To: Stefan Görling
Cc: specs@openid.net
Subject: Re: Making identities
persistent?





This is a good use case and I
think important for both users and IdPs (now OPs [OpenID Provider] per the
latest editor's conference) to consider.

I see a number of options...

1. There has been some discussion regarding a change identifier
extension that would allow you to change your identifier at the relying
party. This would solve the use case and is necessary regardless of the
other options.

2. The OP (in this case AOL.com) could continue to provide an identifier
management page that would allow the user to specify the OP of
choice. This requires the OP to continue to serve the XRDS doc or at
least the indirection to a XRDS doc with the new OP. This is not that
much extra overhead for the OP, but it will likely be a business decision as to
whether to support such a feature.

3. The user gets to choose their OP so they can ensure that they don't get
locked in. This is the ideal behind user-centric.
However, in practice, it will take good education and time for users to
understand the ramifications of their decisions.

Thanks,
George

Stefan Görling wrote: 

Hi everybody,I'm trying to get a grip around your great work and have one issue that I'm not quite clear on, relevant to the discussion of using [EMAIL PROTECTED] identifiers, but also in a more general context. Please let me know if I've simply missunderstood my own question.http://openid.net/specs/openid-authentication-2_0-09.html#anchor48 says:OpenID is decentralized. No central authority must approve or register Relying Parties or Identity Providers. An End User can freely choose which Identity Provider to use. They can preserve their Identifier if they switch Identity Providers.Let us consider the case that I'm an AOL.com customer, and they act as an IdP providing we with an identifier. I use this identifier for 3 years for identity management on most of the services I use, due to the huge success of the standard... However, I'm starting to get fed up with AOL and terminates my agreement with them. Is there any procedure for me to switch to another IdP? How is this done?Best Regards,Stefan Görling___specs mailing listspecs@openid.nethttp://openid.net/mailman/listinfo/specs  




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


RE: Editors Conference Call

2006-10-30 Thread Drummond Reed
Good job, editors!

I look forward to reading the full spec draft when it comes out (though I'll
be travelling, so it won't be until my flight back Friday night that I'll be
able to do a detailed read-through.)

=Drummond 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Recordon, David
Sent: Monday, October 30, 2006 4:51 PM
To: specs@openid.net
Subject: Editors Conference Call

This morning Dick, Josh, and I got on Skype for 2.5 hours to try and
hash through all the remaining proposals.  Unfortunately Brad couldn't
join us, though I did talk to him about some of this stuff as well
beforehand.

 - Authentication Age will be developed as an extension due to questions
around what is the best way for it to work, what features does it need,
etc

 - The field setup_url will be removed from a checkid_immediate
response, rather the RP should fallback to a checkid_setup request to
complete the transaction.  It has been found that in the, albeit few,
implementations of checkid_immediate this is the behavior for the
setup_url anyway.

 - Support bare requests by having the field openid.return_to as
optional in checkid_* requests.  There is a worry of user's not knowing
when they'll be redirected back and when they won't, though that will
only be worked out by allowing this functionality.

 - Clarify that the openid.realm parameter should be used to uniquely
identifier relying parties

 - There are some places where it could be clear in step-by-step
instructions of what an IdP needs to do in various parts of the
protocol, like is done in section 12 for rp's.  Sxip will provide
pointers to where this clarity can be added.

 - Rename Identity Provider to OpenID Provider (IdP - OP) to add
clarity to the term since IdP has a very different meaning in the SAML
and WS-* worlds

 - The spec won't speak to what a RP should do if it has an identifier
like [EMAIL PROTECTED], worried about setting a confusing precedent of
allowing this form of identifier for discovery.  Users are used to
entering, example.com in their URL bar to goto the site, so entering
the same to login doesn't seem like to far of a stretch.  All of OpenID
has a user education challenge and this doesn't seem very different.

 - Spec will say in essence, RP's SHOULD give the text field a user
enters their OpenID Identifier a name attribute with a value of
'openid_identifier', though if a RP wishes to support rich clients it
MUST do so.

 - Dick will be writing a separate document discussing how RPs can
advertise services, logos, etc

 - There cannot be parameters with the same name, make sure spec says
this, we think it does.

 - Josh will be updating his delegation proposal patch to specify two
identifiers for all transactions.  This will create a consistent
paradigm when dealing with delegation or when not.

Goal is to have all of these changes made by end of day Wednesday.  I
doubt I've added enough detail in all places, so feel free to ask for
clarifications or wait to comment on the next draft.

--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: Yet Another Delegation Thread

2006-10-26 Thread Drummond Reed
+1. In this whole discussion, I have three very strong views (which the
editors can take as input into their call today):

1) If RP discovery reveals an IdP-specific identifier, the RP MUST send it
to the IdP because that's what the IdP needs most to serve the user.

2) If the IdP receives an IdP-specific identifier, the IdP can act on it
immediately without needing to perform discovery. There is no such thing as
a stale IdP-specific identifier. The IdP is either authoritative for it or
it is not.

3) Because of (1) and (2), the protocol should make it clear to the IdP when
the IdP is receiving an IdP-specific identifier, i.e., it should not be
ambiguous to the IdP whether the identifier is the Claimed Identifier or an
IdP-specific identifier.

So the whole question in my mind boils down to: even if the RP discovers an
IdP-specific identifier, should the RP *also* send the Claimed Identifier? I
believe there is a strong case for doing so for the reasons discussed in
this thread.

Go for it, editors!

=Drummond 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Josh Hoyt
Sent: Thursday, October 26, 2006 8:28 AM
To: Dick Hardt
Cc: Martin Atkins; specs@openid.net
Subject: Re: Yet Another Delegation Thread

On 10/26/06, Dick Hardt [EMAIL PROTECTED] wrote:
   * If the IdP-specific identifier is not checked by the relying
  party's discovery, the IdP MUST do discovery on every request to
  ensure that it's not making an assertion based on stale information.

 Which is probably a good idea. :-)
 If the IdP is sending both identifiers in a signed response, then
 they both should be valid.

Requiring this discovery adds another (redundant) HTTP request to the
authentication process, which takes time. I'd like to be able to
improve the User Experience by implementing an IdP that would verify
the binding occasionally, but not *every time* the user authenticates.

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: Yet Another Delegation Thread

2006-10-25 Thread Drummond Reed
Dick, the questions you raise are exactly the kinds of tradeoffs the editors
need to discuss on their telecon (I agree this issue could consume an entire
call). I doubt I can add anything more here, so I'll just wish you all
godspeed on the call.

=Drummond 

-Original Message-
From: Dick Hardt [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, October 24, 2006 10:07 PM
To: Drummond Reed
Cc: 'Recordon, David'; specs@openid.net
Subject: Re: Yet Another Delegation Thread

Thanks for the explanation Drummond. I think we need a con call on  
this topic alone ... :-)

On 24-Oct-06, at 6:16 PM, Drummond Reed wrote:
 * But in our discussion today, Josh and David and I boiled down the
 fundamental problem with the single identifier on the wire  
 solutions: as
 long as the RP has the ability to do the mapping between the Claimed
 Identifier and an IdP-specific Identifier (and there are many good  
 reasons
 to allow the RP to do this mapping, including that this is how  
 OpenID 1.1
 works),

Would you elaborate on those good reasons? I'd like to understand  
them because they are not obvious to me.

 then sending only one of these two identifiers on the wire to the
 IdP shuts down an option the IdP and/or user should have. To wit:

   - If only the Claimed Identifier is sent, the IdP is forced to  
 repeat
 discovery if it doesn't recognize it (Josh and David and I believe  
 the IdP
 should not be forced to repeat discovery - it is not required in  
 OpenID 1.1
 and should not be required in OpenID 2.0).

The IdP does not do discovery in OpenID 1.1 because the IdP is not  
aware of the public identifier. The RP is doing it.

Either the IdP is binding the two identifiers, or the RP is doing it  
*after* getting them back unless it preserves state.

A design goal has been to move complexity to the IdP when given a  
choice.


   - If only the IdP-specific Identifier is sent, then the IdP does  
 not have
 the option to assist the user with identifier selection based on  
 the Claimed
 Identifier (which is required for directed identity anyway, and is  
 one of
 the motivations behind this whole thread).

I don't think the RP needs to even understand the IdP-specific  
identifier.


 Our conclusion was that the only way to avoid shutting down one or  
 the other
 of these options is to allow (but not force) the RP to send both  
 identifiers
 using two parameters, and to have the IdP return both parameters,  
 which the
 RP must always verify based on its own discovery.

 That's the state of the state as of our discussion this afternoon.
 Hopefully this will be helpful input into the editor's call(s) this  
 week.

Thanks Drummond.

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


RE: Yet Another Delegation Thread

2006-10-24 Thread Drummond Reed
First, just to make sure intentions are clear, the conversation that David
and I had yesterday (because he happened to be in Seattle) and the
subsequent conversation that David and Josh and I had today (because Josh
had questions about what we posted) were meant only to try to better
understand the issue, not take anything offline. I personally believe that
the remaining 2.0 issues need to be resolved primarily via telecons because
they have proved themselves too hard to work out in email (the XRI TC holds
2 hour telecons weekly almost entirely for this purpose). David and Josh and
I agreed that our discussions today were all preliminary to the telecon(s)
the editors have already agreed to do starting this week.

For this reason I'm hesitant to write anything further on this thread. But
However I'll try to answer Dick's question as succinctly as I can:

* Dick's proposal defined two different identifier parameters, but sent only
one or the other on the wire depending on the initial conditions at the RP.

* David's writeup yesterday also proposed sending only a single identifier
parameter on the wire that would fulfill both roles that Dick's two
identifier parameters filled.

* But in our discussion today, Josh and David and I boiled down the
fundamental problem with the single identifier on the wire solutions: as
long as the RP has the ability to do the mapping between the Claimed
Identifier and an IdP-specific Identifier (and there are many good reasons
to allow the RP to do this mapping, including that this is how OpenID 1.1
works), then sending only one of these two identifiers on the wire to the
IdP shuts down an option the IdP and/or user should have. To wit:

  - If only the Claimed Identifier is sent, the IdP is forced to repeat
discovery if it doesn't recognize it (Josh and David and I believe the IdP
should not be forced to repeat discovery - it is not required in OpenID 1.1
and should not be required in OpenID 2.0).

  - If only the IdP-specific Identifier is sent, then the IdP does not have
the option to assist the user with identifier selection based on the Claimed
Identifier (which is required for directed identity anyway, and is one of
the motivations behind this whole thread). 

Our conclusion was that the only way to avoid shutting down one or the other
of these options is to allow (but not force) the RP to send both identifiers
using two parameters, and to have the IdP return both parameters, which the
RP must always verify based on its own discovery.

That's the state of the state as of our discussion this afternoon.
Hopefully this will be helpful input into the editor's call(s) this week.

=Drummond 



-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Dick Hardt
Sent: Tuesday, October 24, 2006 5:12 PM
To: Recordon, David
Cc: specs@openid.net
Subject: Re: Yet Another Delegation Thread

Can we have those conversations on the list so that everyone  
understands what the goals missed are?

I'd appreciate feedback on the revised proposal I emailed out and  
what is missing from it.

-- Dick

On 24-Oct-06, at 3:45 PM, Recordon, David wrote:

 I honestly wasn't really putting it out as a proposal, rather  
 describing
 more of the different cases involved in all of this.  In any case,
 talking this over more with Josh and Drummond it doesn't actually
 accomplish all of the goals anyway.

 --David

 -Original Message-
 From: Dick Hardt [mailto:[EMAIL PROTECTED]
 Sent: Monday, October 23, 2006 11:04 PM
 To: Drummond Reed
 Cc: Recordon, David; specs@openid.net
 Subject: Re: Yet Another Delegation Thread

 +1

 Glad to see that we have settled on one identifier parameter

 On 23-Oct-06, at 7:07 PM, Drummond Reed wrote:

 Here's another way to summarize the conclusions David and I  
 reached in

 our analysis today:

 1) In OpenID Authentication 1.1, if there is a difference between the
 identifier the user wants to assert to an RP and the identifier the
 IdP wants to assert for the user (lets just call them ID1 and ID2),
 then the mapping from ID1 to ID2 can only be handled by the RP (using
 the OpenID delegate feature).

 2) Josh and Mart have argued that in OpenID Authentication 2.0 an IdP
 should also be able to handle the mapping between ID1 and ID2, and
 indeed in the directed identity use case, the IdP MUST handle this
 mapping.

 3) What David and I realized today is that there are even use cases
 for BOTH the RP and IdP doing the mapping. In other words, even if an
 RP maps from
 ID1 to ID2 and passes ID2 to the IdP, there shouldn't be anything to
 prevent the IdP from mapping ID2 to ID3 and passing ID3 back to  
 the RP

 (as long as the RP verifies the IdP is authoritative for ID3).
 Example: I log into RP using one URI#1, which maps in my XRDS  
 document

 to another IdP- specific URI#2, and then when logging into my IdP it
 reminds me that I previously used URI#3 at this RP, so I choose  
 URI#3.

 4) Therefore, as long as the protocol

RE: XRI confusion

2006-10-19 Thread Drummond Reed
Dick, you are right that there are usability challenges with i-numbers and
XDI.org and the i-broker community is working to address them. Although
persistent identifiers are used everywhere in local systems (directories,
databases, object stores, etc.), and the concept has been around at the
Internet level since the late '90s in the form of URNs
(http://en.wikipedia.org/wiki/Uniform_Resource_Name), the need to integrate
them into a digital identity layer is only just emerging.

As with each new Internet layer, there's some stuff that just has to get
figured out ;-)

=Drummond 

-Original Message-
From: Dick Hardt [mailto:[EMAIL PROTECTED] 
Sent: Thursday, October 19, 2006 9:26 AM
To: Drummond Reed
Cc: 'Recordon, David'; 'Martin Atkins'; specs@openid.net
Subject: Re: XRI confusion

That provides clarity on the process, thanks. If the user knows that  
their i-name has been changed,
then when you write here:

http://www.lifewiki.net/openid/ConsolidatedDelegationProposal

Summary of Motivations:
...
4. Enable RPs to take advantage of XRI CanonicalDs to protect
End-Users
from ever having their Portable Identifier reassigned (and thus  
their identity taken over).

... his is just in case they don't get alerted to their i-name being  
changed?

btw: I have no idea what my i-numbers are, and it was not clear to me  
that I had them when I got them. I think there are some real  
usability issues here, but this is likely not the place to address  
those. :-)

-- Dick

On 19-Oct-06, at 8:12 AM, Drummond Reed wrote:

 Exactly. An i-name being reassigned is very similar to a domain  
 name being
 reassigned -- the previous owner is going to know they no longer  
 own it.

 For example, if you register blame.ca, you're going to receive  
 multiple
 notices from your DNS registrar that you need to renew it, and if  
 you don't,
 you know it is almost certain to be reassigned. The same is true  
 for i-name
 registrants.

 With regard to i-numbers, every registrant is notified of their i- 
 number,
 and their i-broker retains a record of the i-number. Because an i- 
 number is
 NEVER reassigned, if a registrant chooses not to renew an i-name, they
 ALWAYS have their i-number.

 Note that since the i-name and i-number are directly synonymous,  
 i.e., the
 i-number resolves the same XRDS as the i-name, if a registrant know  
 their
 i-number, they can always use it to login at any OpenID RP at which  
 they had
 previously used any i-name synonym for that i-number.

 =Drummond

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On  
 Behalf
 Of Recordon, David
 Sent: Thursday, October 19, 2006 4:09 AM
 To: Dick Hardt; Martin Atkins
 Cc: specs@openid.net
 Subject: RE: XRI confusion

 How would Alice buy =foo when Bob already owns it?

 --David

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
 Behalf Of Dick Hardt
 Sent: Thursday, October 19, 2006 3:58 AM
 To: Martin Atkins
 Cc: specs@openid.net
 Subject: Re: XRI confusion


 On 19-Oct-06, at 12:44 AM, Martin Atkins wrote:

 Dick Hardt wrote:

 How would a user ever learn what their CanonicalID is?

 The user doesn't need to know his i-number. The system discovers that
 for him.

 If there Portable Identifier (i-name) is reassigned, then they will
 be sent to an IdP for the new Canonical ID is, expecting credentials
 from the new owner. The user will never make it back to the RP, and
 they will have no easy way of proving they are the owner of the
 CanonicalID.

 I don't really understand this paragraph, but when the i-name is
 reassigned it'll cease to point at the same XRDS and will thus not
 point at the IdP anymore - unless the new owner also has an account
 with that IdP, of course. But they have a different i-number, so the
 IdP can distinguish them.

 Bob has the i-name =foo. Alice has =foo reassigned to her. Bob does  
 not
 know this. Bob goes to an RP, enters =foo and gets sent somewhere he
 cannot authenticate since =foo resolves somewhere else.

 Bob does not know what to do. =foo does not resolve to his i-number  
 any
 more. How does he find out what it is so that he can get a his i- name
 to point to it?


 Additionally, in the proposal, the i-name is not sent from the RP to
 the IdP, so how does the IdP know which i-name to address the user
 as?

 I would hope that an IdP, given that I've already established a
 relationship with it, can find something better to address me with
 than a URI. It should be calling me Martin.

 Perhaps, although I would like my IdP to let me know which  
 Identifier I
 am going to present to the RP.

 -- 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

RE: Question: multiple IdPs?

2006-10-18 Thread Drummond Reed
In the directed identity case, the IdP URL or XRI you give to the RP
resolves to your IdP's XRDS document. Each of your IdPs would have a
different one. If they support directed identity, each would have a Service
with a Type tag value of http://openid.net/identifier_select/2.0. This
service endpoint would not have an OpenID:Delegate tag (or if it does the
spec should be clear that it is ignored for this service type) since this
service provides directed identity authentication for everyone at that IdP.

=Drummond 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Dick Hardt
Sent: Tuesday, October 17, 2006 11:25 PM
To: specs@openid.net
Subject: Question: multiple IdPs?

I would like to use different IdPs for my vanity URL, blame.ca. In an  
OpenID 2.0 world, I can provide either of my IdP URLs to the RP and  
then select blame.ca and login.

Does this work? What having two openid.server tags suffice? How would  
the RP know which delegate tag goes with which IdP? The spec is not  
silent on this.

( and yes, another argument for having one identifier so that the RP  
does not have to figure out anything about the delegate tag since it  
does not do anything with it anyway!)

-- 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: Consolidated Delegate Proposal

2006-10-18 Thread Drummond Reed
I don't think anything is missing from your previous posts, nor do I think
you've missed anything from other's previous posts. I think we've discussed
this issue thoroughly from all sides. 

As you say, It is a different way of thinking about what OpenID is doing.
In other words, it's a worldview thing. One worldview is that the IdP should
handle all delegation/synonym management. Another worldview is that the RP
can handle it in certain use cases and the IdP in others. The first
worldview requires only one identifier parameter. The latter worldview works
better with two.

When it comes down to a conflict in worldviews, there's no point in further
technical debate. We just have to vote and move on. 

=Drummond 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Dick Hardt
Sent: Tuesday, October 17, 2006 10:59 PM
To: Recordon, David
Cc: specs@openid.net
Subject: Re: Consolidated Delegate Proposal

I don't see there being general consensus.

I think Chris Drake was supportive of there being less disclosure as  
well.

Josh said it could be any of the three, but preferred two parameters.

Brad did not really care.

I do care and would like to see direct criticism on the explanation I  
wrote about how the protocol works.

It is a different way of thinking about what OpenID is doing, and I  
think it is a useful view that makes it simpler. The RP does not need  
to worry about the delegation mechanism. There is only one identifier  
moving around. The concept that there is an RP identifier and an IdP  
identifier is not needed.

What is missing from my previous posts? Throw me a bloody bone here  
so that I know what I am missing.

-- Dick


On 17-Oct-06, at 3:20 PM, Recordon, David wrote:

 I'm also echoing what Josh has said.  There has been significant
 discussion on this issue and there seems to be general consensus,
 excluding Sxip, that the protocol should have two parameters.

 --David

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
 Behalf Of Josh Hoyt
 Sent: Tuesday, October 17, 2006 5:24 PM
 To: Dick Hardt
 Cc: specs@openid.net
 Subject: Re: Consolidated Delegate Proposal

 On 10/17/06, Dick Hardt [EMAIL PROTECTED] wrote:
 2. It is explicit what is going on from an implementation and
 specification perspective

 And I see the opposite. What the RP sends the IdP is just a hint.
 What the IdP sends the RP is authoritative.
 I see having two parameters as implying more meaning then is really
 there.

 The IdP sending two identifiers *in the response* as the important  
 part.
 The IdP is only authoritative *if discovery says it is*. There is no
 more meaning to the response than I am asserting that when you do
 discovery, you will find that this information is true. What other
 meaning do you see?

 Did you read what I wrote? Was there something you did not  
 understand?

 Perhaps you can point out what you disagree about what I wrote?

 It's possible that I misinterpreted the RP is figuring them out
 anyway. I took this as questioning why two identifiers is an
 improvement over the current (delegate only) model.

 My answer to this question was it is explicit what is going on  
 from an
 implementation and specification perspective. This statement was
 motivated by implementation experience and experience writing about  
 this
 issue in OpenID 2 drafts. I believe that the two identifier approach
 will be easier.

 I also believe that if I had spent the time that I've spent arguing
 about this issue in documentation and implementation, the world  
 would be
 better off, regardless of which of the three viable options for
 identifier portability had been chosen.

 I repeat, ALL THREE OPTIONS ARE VIABLE. There are trade-offs for  
 all of
 them. You know which trade-offs I'd make. I know which ones you'd  
 make.
 We just need to make a decision so that we can spend our energy and  
 time
 on things that will make a difference to end-users. This is my last  
 word
 on this list about this issue, unless there is significant insight.  
 I am
 not going to change my votes.

 If you want to discuss it more off-list, I'm willing, but I think  
 that'd
 just be wasting both of our time.

 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

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


RE: Identifier portability: the fundamental issue

2006-10-16 Thread Drummond Reed
+1. Trust is not a boolean. Martin, that's very quotable. Can I attribute
it to you?

=Drummond 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Martin Atkins
Sent: Monday, October 16, 2006 12:25 PM
To: specs@openid.net
Subject: Re: Identifier portability: the fundamental issue

Chris Drake wrote:
 
 There seem to be a lot of people on this list who want to hate and
 loathe the IdP, and grant all power to the RP.  I do not understand
 this reasoning:  our users will select the IdP they trust and like,
 then they will be using a multitude of possibly hostile RPs
 thereafter: the reverse is simply not true.
 

If I'm using one IdP to assert my primary public identity, they can 
hypothetically develop quite a profile about me. I probably don't mind 
too much in most cases, because I researched them and found that they 
are a good provider and won't sell my data out to the bad guys.

However, there might be some things I want to do (for example, posting 
locally-prohibited speech on a public forum) that I don't want attached 
in any way, shape or form to my public identity. The trust relationship 
I have with that IdP probably isn't enough for this; if there is any 
record at all of any association between these two identities, as 
friendly as my IdP may be, there is a chance that it will be ceased by 
court order, or leaked by an insider, which might lead to me getting in 
serious legal trouble.

This is just one (perhaps extreme) example of why my trust in my IdP is 
not universal and all-encompassing. Trust is not a boolean.


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


RE: Summarizing Where We're At

2006-10-16 Thread Drummond Reed
My votes on three issues (0 on everything else):

Consolidated Delegation Proposal
 * -1 on status quo (draft 10)
 * +1 on two-identifier

Change default session type
 * +1

Bare request
 * +1

=Drummond 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Recordon, David
Sent: Monday, October 16, 2006 3:24 PM
To: Josh Hoyt; specs@openid.net
Subject: RE: Summarizing Where We're At

And here are my votes:

Request nonce and name
 * Take no action

Authentication age
 * -1, write as an extension first

Remove setup_url
 * 0 for removing, +1 for asking feedback from implementers

Consolidated Delegation Proposal
 * -1 on status quo (draft 10)
 * 0  on single-identifier
 * +1 on two-identifier

Change default session type
 * +1

Bare request
 * 0

--David


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Josh
Hoyt
Sent: Monday, October 16, 2006 11:21 AM
To: Recordon, David
Cc: specs@openid.net
Subject: Re: Summarizing Where We're At

Here are my reactions to what's outstanding:

On 10/15/06, Recordon, David [EMAIL PROTECTED] wrote:
 * Request Nonce and Name
  - Has been partially implemented, openid.nonce - 
 openid.response_nonce, no agreement on the need of a request nonce 
 specifically, rather discussion has evolved into allowing a RP to pass

 appdata like in Yahoo's BBAuth.  No formal proposal on the table 
 yet, thus will not be included in this version.

Take no action

 * Authentication Age
  - Re-proposed today adding clarity in motivation, general consensus 
 is needed to add to specification.

-1

 * Remove setup_url
  - Little discussion and no general consensus to do so.  Rather seems 
 asking for feedback from checkid_immediate implementers on the 
 parameter would be beneficial at this time.

+1

 * Consolidated Delegation Proposal
  - Very active discussion, the only proposal I'm willing to stall the 
 spec for.  Seems very important a strong conceptual model is created 
 at this time.

-0 on status quo (draft 10)
+0 on single-identifier
+1 on two-identifier

 * Change Default session_type
  - Proposed, no discussion yet.

Will address in separate message

 * Bare Request
  - Proposed, no discussion yet.

-0 (YAGNI)

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: Re[2]: Identifier portability: the fundamental issue

2006-10-16 Thread Drummond Reed
Chris,

I think you may have me mistaken for somebody else on the list (DR is also
David Recordon). I'm a big fan of IdP-initiated login and privacy protection
in OpenID.

However as much as I think that's an important use case, there's also many
use cases around using a public, omnidirectional identifier. So OpenID
should accommodate both.

=Drummond 

-Original Message-
From: Chris Drake [mailto:[EMAIL PROTECTED] 
Sent: Monday, October 16, 2006 8:29 PM
To: Drummond Reed
Cc: 'Martin Atkins'; specs@openid.net
Subject: Re[2]: Identifier portability: the fundamental issue

Hi Drummond,

DR ... if there is any record at all of any association between these
DR two identities, ...

double-blind anonymous authentication solves this problem.  The RP
knows nothing more about you besides:
A) you're authenticated, and/or
B) you've been here before (eg: have signed up for an account)
The IdP knows merely
C) That you wanted to log in somewhere

The RP does not know your ID or even your IdP, and your IdP does not
know what site you logged in to.

I have a working proof-of-concept that I demonstrated to a few people
some months back, let me know if you've not seen it, and I'll send
over the URL

In a nutshell - this relies on uniform nonce formats and asymmetric
cryptography (so the RP and IdP can talk between one another without
making any actual contact - the browser and/or user carry the
authentication payloads forth and back without referrer URLs or any
other info that can link the 2 sites (RP/IdP) together).

Besides all that - the normal use case for an IdP in OpenID world
(remember: decentralized) will be someone running some open-source
code on their own server, so trust in this instance *is* boolean: at
least in so far as if there's anything for someone to not be
trustworthy about themselves for - it won't be the fault of their IdP
code PROVIDING their IdP has provided them with IdP-initiated logins
in order to allow this user to protect their own privacy in the first
place.

Court orders are what I termed 3.5. Authorized exploitation in my
threat list, and insider leaks I called 1.3.6. physical attack of
server resources (eg: server/hosting-facility compromise) - there's
another 98 other threats to keep in mind here as well:-
http://chrisdrake.com/Comprehensive_list_of_Threats_to_Authentication_Proced
ures_and_Data.html

While your example might seem extreme, the consequences are also
extreme (or fatal, if you live someplace like China) - which is why I
take privacy so seriously.  Stick Himalayas video into google news
if you want to watch what Chinese do to their own people when found
trying to visit the Dalai Lama.  Now - how comfortable are you with
the idea of letting 1.5 billion Chinese people use OpenID without
making it easy to help them protect their own privacy ?

There's a big picture here, and it's not about meeting some arbitrary
deadline or saving a day or two of coding work - it's about producing
something that works, and can be deployed ethically.

Take a long hard look at that Nun lying dead in the snow, then tell me
you still believe there's no need for IdP-initiated privacy protection
in OpenID.

Kind Regards,
Chris Drake,
=1id.com


Tuesday, October 17, 2006, 7:29:00 AM, you wrote:

DR +1. Trust is not a boolean. Martin, that's very quotable. Can I
attribute
DR it to you?

DR =Drummond 

DR -Original Message-
DR From: [EMAIL PROTECTED]
DR [mailto:[EMAIL PROTECTED] On Behalf
DR Of Martin Atkins
DR Sent: Monday, October 16, 2006 12:25 PM
DR To: specs@openid.net
DR Subject: Re: Identifier portability: the fundamental issue

DR Chris Drake wrote:
 
 There seem to be a lot of people on this list who want to hate and
 loathe the IdP, and grant all power to the RP.  I do not understand
 this reasoning:  our users will select the IdP they trust and like,
 then they will be using a multitude of possibly hostile RPs
 thereafter: the reverse is simply not true.
 

DR If I'm using one IdP to assert my primary public identity, they can
DR hypothetically develop quite a profile about me. I probably don't mind
DR too much in most cases, because I researched them and found that they
DR are a good provider and won't sell my data out to the bad guys.

DR However, there might be some things I want to do (for example, posting
DR locally-prohibited speech on a public forum) that I don't want attached
DR in any way, shape or form to my public identity. The trust relationship
DR I have with that IdP probably isn't enough for this; if there is any
DR record at all of any association between these two identities, as 
DR friendly as my IdP may be, there is a chance that it will be ceased by
DR court order, or leaked by an insider, which might lead to me getting in
DR serious legal trouble.

DR This is just one (perhaps extreme) example of why my trust in my IdP is
DR not universal and all-encompassing. Trust is not a boolean.


DR ___
DR specs mailing list

IdP term in spec (was RE: Delegation discussion summary)

2006-10-15 Thread Drummond Reed
Suggestion: sidestep the issue completely and in the spec -- and everywhere
else -- just call it OpenID provider. It's a simple concatenation of
OpenID and service provider, so everyone gets it, but nobody will
associate it with SAML or federation or anything else.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Johannes Ernst
Sent: Saturday, October 14, 2006 11:37 PM
To: specs@openid.net
Subject: Re: Delegation discussion summary

We call it identity host at NetMesh. It's close enough to identity  
provider so people understand it quickly, but does not have the  
provider part to it (duh).

On Oct 14, 2006, at 20:46, Scott Kveton wrote:

 I would propose that the term Homesite be used when prompting the
 user to type in their IdP. I think the term Identity Provider is
 overloaded and not user friendly.

 As per my last email I feel the same way about identity provider  
 as well
 ... I agree with Dick; too overloaded and not user friendly.

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

Johannes Ernst
NetMesh Inc.


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


RE: Identifier portability: the fundamental issue

2006-10-14 Thread Drummond Reed
Chris,

I totally agree that: a) OpenID Authentication 2.0 should support yours
scenario of IdP-initiated login, and b) that this enables a whole range of
privacy solutions, many of which can be supported by IdP innovation.

If IdP-initiated login were the only use case, then only one identifier
would be needed. It's the use cases for RP-initiated login that argue for
having a second identifier parameter in the protocol.

=Drummond 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Chris Drake
Sent: Friday, October 13, 2006 9:19 PM
To: specs@openid.net
Subject: Re: Identifier portability: the fundamental issue

Hi Drummond,

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

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

Please explain?  If I've got an OpenID URL (eg: my vanity domain), I
can transfer this via DNS (or just update my OpenID LINK).  If
I've got an i-name, I can transfer this too.  Where's the lock in ?

I do not believe the RP needs to know the IdP-specific identifier ever
(worse: I think it should never be allowed to know it, or even be
allowed to see it!).  Yes - we need 2 identifiers - but from the point
of view of the specs - the OpenID protocol really only needs to deal
with one.

There seem to be a lot of people on this list who want to hate and
loathe the IdP, and grant all power to the RP.  I do not understand
this reasoning:  our users will select the IdP they trust and like,
then they will be using a multitude of possibly hostile RPs
thereafter: the reverse is simply not true.

Can we not adopt my earlier suggestion: just ensure OpenID can permit
IdP-initiated logins.  This permits every scenario of portability (and
privacy) that everyone wants, without us having to continue to debate
it ?

This really *is* only an hour or two's worth of code: after which,
market forces can decide which bells and whistles relating to
portability and privacy the IdPs choose to implement - from the OpenID
point of view, it's all just going to work.

Kind Regards,
Chris Drake,
=1id.com


Saturday, October 14, 2006, 5:59:23 AM, you wrote:



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

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

DR *

DR Please post if you do not agree with this postulate.

DR =Drummond 





DR ___
DR specs mailing list
DR specs@openid.net
DR 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: Delegation discussion summary

2006-10-13 Thread Drummond Reed
Hans,

This has come up a few times and the mapping between the portable identifier
and the IdP-specific identifier is available in public XRDS documents. So
there's no point in trying to hide that information from the IdP -- and it
may even be misleading to suggest to end-users that they could try to do so.

=Drummond  

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Granqvist, Hans
Sent: Friday, October 13, 2006 8:52 AM
To: Josh Hoyt; specs@openid.net
Subject: RE: Delegation discussion summary

I can see potential use-cases where Alice doesn't want the 
idp to know what her portable URL is.  This would not work
if the protocol requires both as per below.  Can it be
solved by sending a hash of the portable identifier?


 -Original Message-
 From: [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED] On Behalf Of Josh Hoyt
 Sent: Thursday, October 12, 2006 10:29 AM
 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 is communicated between the relying 
 party and the IdP. When a relying party discovers that it is 
 requesting authentication for a portable identifier, it must 
 keep that state available for processing the response, since 
 the response message does not contain the portable identifier at all.
 
 Request and response messages for this mechanism both use the 
 following field::
 
   openid.identity = http://my.idp.specific.url/
 
 This mechanism has a few drawbacks:
 
  * The relying party must manage state information for the duration of
the transaction.
 
  * The authentication messages are potentially confusing, since the
authentication response is not meaningful without the context of
the initiation, and the IdP-specific identifier does not even have
to be a valid OpenID identifier.
 
   * The IdP *cannot* be aware that it is using a portable identifier,
so the IdP cannot assist the user in making decisions for different
identifiers. For example, a user might wish to be prompted for
confirmation each time he used one identifier, but allow automatic
approval for another.
 
   * IdP-driven identifier selection in the OpenID 2.0 
 specification (up
to draft 9) cannot return assertions for portable identifiers,
because the verification algorithm will fail.
 
   * Portable identifiers must be treated differently from IdP-issued
identifiers by the code running on the relying party
 
 
 Proposed changes
 
 
 All of the changes to delegation that have been proposed 
 retain the important features of portable identifier support. 
 Additionally, they all retain the same basic structure, where 
 the IdP-specific identifier is available from the standard 
 discovery process. Primarily, the proposals change what data 
 is available in the protocol messages, the relationship of 
 the request to the response, and/or the party who is 
 responsible for discovering the IdP-specific identifier for 
 the portable identifier.
 
 Both of the proposed changes 

RE: Delegation discussion summary

2006-10-13 Thread Drummond Reed
 But I suggest we move that terminology discussion to the marketing list.
 

 What marketing list?

http://lists.iwantmyopenid.org/mailman/listinfo/marketing.

=Drummond 

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


Use of i-numbers (was RE: Consolidated Delegate Proposal)

2006-10-13 Thread Drummond Reed
Martin wrote:

I think this is the intention, though it does show an interesting 
inconsistency between the use of XRIs and the use of i-numbers. I 
currently have three URL-based identifiers all pointing at the same 
server and the same Yadis document, yet those identifiers are distinct. 
However, in the comparable XRI case, it would appear that those 
identifiers would all be considered to be the same.

If they point to the exact same XRDS document with the same i-number as the
CanonicalID, that would establish all three URLs and the CanonicalID
i-number as synonyms (yes, it is possible to have URLs and XRIs that are
synonyms). In XRI Resolution 2.0 Working Draft 11 we are adding a new
BackRef element that will enable an XRDS document to back reference any type
of identifier that points to it, such as a URL, so you can machine-verify
the back reference if you want.

If you wanted to keep the three URLs as distinct, separate identities, point
them at three different XRDS documents with different i-numbers.

I wonder how easy it is to get hold of new i-numbers. If they are 
basically throw-away cheap, then I'm able to decide for myself how to 
distribute my mappings to separate them. However, if these i-numbers are 
going to be expensive (for some sense of the word) to aquire, I've got 
less freedom in this respect. Drummond?

The short answer is that delegated i-numbers (and this is the federated
identifier meaning of the term delegation) are as throw-away cheap as
URL (at the path level), third-level DNS names, or any other form of
delegated identifier. The cost is all in resolution, i.e., someone
somewhere maintaining a registry that will point you to the XRDS document if
you resolve it. 

=Drummond 

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


RE: Delegation discussion summary

2006-10-13 Thread Drummond Reed
 Marius wrote:

 I was suggesting that portability can be resolved between the user  
 and
 the IdP. I cannot see how the protocol can help this by passing two
 identifiers. And if only the portable identifier is passed then  
 there is
 no need to mention the IdP-specific identifier.

 Marius, see the analysis at
 http://www.lifewiki.net/openid/ConsolidatedDelegationProposal, now  
 updated
 to include Josh's lastest thinking from
 http://openid.net/pipermail/specs/2006-October/000357.html.

 In sum, not being able to send the IdP-specific identifier: a)  
 forces the
 IdP to redo resolution, which is unnecessary and slows performance,  
 and

Not necessarily. When you register with the IdP most likely you will  
claim all your portable identifiers with this IdP, so the IdP knows  
about them.

With XRI i-name/i-number infrastructure that's neither practical nor
desirable. With XRIs, users control their own synonyms, i.e., I can register
a delegated i-name within a specific community (for example, at
@example.community I could register @example.community*drummond) and then
point that at my personal i-name (=drummond.reed) and the IdP for
=drummond.reed will never know -- and doesn't need to know. I could go to
any RP and login in as @example.community*drummond, the RP will resolve this
to =drummond.reed (through the way XRI resolution automatically handles
reference processing -- let me know if you want more info about this), and
end out storing the CanonicalID i-number for =drummond.reed (which is
=!F83.62B1.44F.2813).

 b) prevents the protocol from being stateless.

How? The RP deals only with the portable identifier and this is the  
only thing the IdP sends back. Why do you need state?

It follows from the above. But this is so important that I'm going to send a
separate message about it.

=Drummond 

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


Identifier portability: the fundamental issue

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


RE: Identifier portability: the fundamental issue

2006-10-13 Thread Drummond Reed
  Drummond wrote:
 
  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).

 Hans wrote:

 There is no reason why the idp MUST require to know both
 identifiers for identifier portability to be possible in
 the system.

Brad wrote:

Existence proof:  OpenID 1.1 does identifier portability without two
identifiers in the spec.

Just to clarify: the postulate above did not mean to imply there must be
two different identifiers in the spec/protocol. It was just meant to assert
that the principle of identifier portability (upon which we already have
consensus) requires that it be possible for the RP and IdP to use two
different identifiers.

I was hoping to inch our way towards consensus here by seeing if we had
agreement on this second principle (as some messages have been implying that
IdP-specific identifiers were not needed at all).

And despite all the but it can't be stateless without two! noise, it
actually can:  you put the portable identifier in the return_to URL and
verify it again when you get the signature back from the IdP.  That is,
verify the mapping from portable - IdP-specific still holds.  Because you
can't just trust the 1 (or 2) values you get back from the IdP, otherwise
the IdP (which could be malicious) could be fucking with you, asserting a
portable identifier which it's not actually permitted to do, according to
the portable identifer's YADIS/head/etc.

Good point. I've never figured an attack vector for the RP to send the wrong
identifiers to the IdP, since the RP is just fooling itself. But I agree
there can be one for a malicious IdP to return the wrong ones to an RP.

So with 1 or 2, you still need to verify, but that verification doesn't
have to be painful:  you can cache it.  But that's state!  omg!  Okay,
so don't cache it and re-check it.  But OpenID's been all about the
state(caching) vs. roundtrip(slow) for some time, so it's a fair tradeoff.

Agreed.

Counter-argument:  but OpenID 1.1 does have two parameters:  one's just in
the return_to URL and managed by the client library, arguably in its own
ugly namespace (not IdP/RP managed, not openid., but something else...
the Perl library uses oic. or something).  So then it's harder to
document the correct behavior to people (RPs should verify the mapping
when you get a signature!) because the parameter names aren't consistent
between RP clients.

Agreed, and you articulated well the reasons for doing it at the spec level.

So whether it's in the spec formally or not, I don't really care.  But the
spec MUST contain details on the precautions a RP should take.

Yup.(Got that, editors?)

=Drummond 


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


RE: Delegation discussion summary

2006-10-12 Thread Drummond Reed
+1. Josh, you did a great job of not just distilling it down to the essence,
but also nailing the right semantics for the underlying feature, which is
identifier portability.

Nice work.

=Drummond 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Josh Hoyt
Sent: Thursday, October 12, 2006 10:29 AM
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 is communicated between the relying party and the IdP. When a
relying party discovers that it is requesting authentication for a
portable identifier, it must keep that state available for processing
the response, since the response message does not contain the portable
identifier at all.

Request and response messages for this mechanism both use the
following field::

  openid.identity = http://my.idp.specific.url/

This mechanism has a few drawbacks:

 * The relying party must manage state information for the duration of
   the transaction.

 * The authentication messages are potentially confusing, since the
   authentication response is not meaningful without the context of
   the initiation, and the IdP-specific identifier does not even have
   to be a valid OpenID identifier.

  * The IdP *cannot* be aware that it is using a portable identifier,
   so the IdP cannot assist the user in making decisions for different
   identifiers. For example, a user might wish to be prompted for
   confirmation each time he used one identifier, but allow automatic
   approval for another.

  * IdP-driven identifier selection in the OpenID 2.0 specification (up
   to draft 9) cannot return assertions for portable identifiers,
   because the verification algorithm will fail.

  * Portable identifiers must be treated differently from IdP-issued
   identifiers by the code running on the relying party


Proposed changes


All of the changes to delegation that have been proposed retain the
important features of portable identifier support. Additionally, they
all retain the same basic structure, where the IdP-specific identifier
is available from the standard discovery process. Primarily, the
proposals change what data is available in the protocol messages, the
relationship of the request to the response, and/or the party who is
responsible for discovering the IdP-specific identifier for the
portable identifier.

Both of the proposed changes to the response messages include the
portable identifier in the authentication response. Changing the
response to contain the portable identifier removes the burden of
maintaining that state from the relying party. Removing this
dependency on transaction state enables portable identifiers to be
used in both IdP-driven identifier selection and IdP-initiated
authentication (bare response) [3]_.

Neither proposal outlined here changes the protocol unless a portable
identifier is used.


Both portable and IdP-specific identifiers
--

Include both the portable identifier and the IdP-specific identifier
in the request and response ([4]_ and
[5]_)::

  openid.identity = 

RE: Delegation discussion summary

2006-10-12 Thread Drummond Reed
+1 to Josh's point. IMHO identifier portability is sacred. If anyone
disagrees, please post, can we assume we have consensus on this?

=Drummond 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Josh Hoyt
Sent: Thursday, October 12, 2006 8:56 PM
To: Marius Scurtescu
Cc: specs@openid.net
Subject: Re: Delegation discussion summary

On 10/12/06, Marius Scurtescu [EMAIL PROTECTED] wrote:
 The protocol does not need to touch on IdP-specific identifiers (aka
 delegated identifiers) at all IMO.

If there is a specified mechanism that must be supported for using a
portable identifier, all IdPs will support it, so identifiers will
actually be portable. You'd have a very difficult time trying to get
people here to remove portable identifier support from the OpenID
protocol.

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

2006-10-12 Thread Drummond Reed
Title: RE: Delegation discussion summary








+1 to getting it done. This area of
terminology is more a usability/marketing issue at this point. I agree we need to
converge on good, simple user-facing terms for describing OpenID in ways ordinary
Web users can easily understand. Although I have great respect for Dick 
Sxips pioneering work in this area, I dont believe terms that use
the word site are the right metaphor, and the concept of membersite,
while good for the context Sxip originally used it, would send the wrong
message about OpenID.



But I suggest we move that terminology
discussion to the marketing list.



=Drummond 











From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Recordon, David
Sent: Thursday, October 12, 2006
9:04 PM
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 

RE: Consolidated Delegate Proposal

2006-10-10 Thread Drummond Reed
David,

Based on feedback, I've backed openid.display out of the consolidated
proposal at http://www.lifewiki.net/openid/ConsolidatedDelegationProposal. 

This simplifies it to just two parameters, openid.identity and
openid.rpuserid, which I believe now meet both Josh's and Martin's use
cases.

=Drummond 

-Original Message-
From: Recordon, David [mailto:[EMAIL PROTECTED] 
Sent: Monday, October 09, 2006 9:38 AM
To: Drummond Reed; specs@openid.net
Subject: RE: Consolidated Delegate Proposal

In terms of openid.display, shouldn't the IdP greet the user in whatever
manner it uses?  Thus if the user has an account on the IdP, the IdP
should always greet the user in the same manner with it.  Seems like
both a usability, phishing, and potential XSS issue if the IdP greets
the user with a string from the RP.

Am I just missing something there?

--David

-Original Message-
From: Drummond Reed [mailto:[EMAIL PROTECTED] 
Sent: Monday, October 09, 2006 1:20 AM
To: Recordon, David; specs@openid.net
Subject: RE: Consolidated Delegate Proposal

David Recordon wrote:

Read through it
(http://www.lifewiki.net/openid/ConsolidatedDelegationProposal),
and I'm liking how it really clears up delegation.  A few questions:

1) In case 1, is what the user typed in ever sent from the RP to the 
IdP?  What if it is an OpenID Auth 2.0 IdP, but the user entered their 
identifier on the RP?  Or in the case where the IdP supports multiple 
identifiers for the user, shouldn't the RP send what the user entered 
so the user doesn't have to choose it again at their IdP?

Case 1 is the directed identity case. The RP *could* send what the user
types in at the RP (the identifier for the IdP's directed identity
server), but since the RP knows (from the OpenID service type) that this
is an anonymous login, and thus that the RP needs to get
openid.rd_user_id *back* from the IdP, it seemed better for the RP not
to send anything. This way you never break the rule that the IdP never
changes any of the identifier parameters than an RP sends it.

2) This may also be part of my first question, but why is there such a 
delta between case 1 and cases 2 and 3?  How does the RP know to use 
case 1 versus case 2, they seem quite similar in their explanation?

Again, Case 1 is the directed identity case, that's why it's so unusual.
The way the RP differentiates between case 1 and cases 2/3/4/5 is that
only in case 1 is the value Type attribute in the OpenID service
endpoint http://openid.net/identifier_select/2.0;.

I went back and rewrote the page to make this much clearer.

3) What is openid.display used for?

The complete explanation was in the latter part of
http://openid.net/pipermail/specs/2006-October/000278.html. But to make
the consolidated proposal easier to review, I added a Summary of
Motivations
section at the start and put a section at the end explaining the
motivation for openid.display. 

4) In the rules, don't you mean the IdP must return the value of the 
rp_user_id for the RP to key off of, not the value of identity?

Yes, sorry, this was unclear. What I meant was that since the RP must
ALWAYS send openid.identity, the RP could *ALWAYS* count on this in the
response.
However you're right that as far as a persistent key goes 

I think this is getting there, just either needs to be tightened up or 
the different flows better explained.

I think it just needed to be better explained. Also, Josh, note that
when I went back to edit this tonight, I found the parameter name
openid.rp_user_id was driving the wiki markup nuts. So I changed it to
just openid.rpuserid. Personally, I think this reads fine and
eliminates the awkward underscores. I hope you agree.

=Drummond 



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


RE: PROPOSAL: OpenID Authentication Flow and how delegate fits in

2006-10-10 Thread Drummond Reed
Dick,

While I think I followed most of what you say here, I'm not sure what the
exact proposal is. Are you proposing to remove the openid:delegate element
in 2.0? And replace it with an indirect identifier request protocol (your
step 3 below)?

=Drummond 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Dick Hardt
Sent: Monday, October 09, 2006 10:15 PM
To: specs@openid.net
Subject: PROPOSAL: OpenID Authentication Flow and how delegate fits in

I'll start off with a couple new definitions so that we are not hung  
up on what terms mean:

supplied_identifier := what the user types into the RP's form
verified_identifier := the identifier that the IdP says the user is

When looking at the OpenID protocol, the openid.identity sent from  
the RP to the IdP can be thought of as just a hint as to what  
verified_identifier the user wants to be at the RP. Given that, I  
would describe the flow as such:

1) User provides a supplied_identifier to the RP. The user may type  
this into a form which will post the supplied_identifier to the RP's  
login_url or a software agent may post this to the login_url. The  
supplied_identifier may be an:
OpenID URL
iname
IdP URL

2) The RP then does the appropriate discovery on supplied_identifier  
to find the IdP's entry point and functionality supported. The  
delegate tag is ignored if present.

3) If the RP wants to get a verified_identifier for the user, the RP  
sends an indirect message to the IdP containing  
openid.identity=supplied_identifier, otherwise openid.identity=none  
to indicate it does not want a verified_identifier.

4) if a verified_identifier was requested, the IdP determines which  
verified_identifier the user would like to be with the RP, and then  
sends an indirect message with  openid.identity=verified_identifier  
to the RP. Although the user may have typed in one OpenID URL or  
iname, a different one could be in the response back to the RP.

5) If the RP has not already determined that the IdP is authorative  
for verified_identifier, then the RP does discovery on the  
verified_identifier to confirm the IdP is authoritative.

+ The IdP knows what the user typed into the form at the RP since  
that is what is sent to the IdP.
+ The IdP can display a friendly name to the user as to what they are  
releasing.
+ The IdP can assist the user in determining which  
verified_identifier they want to be at a site. Eg. the user may have  
forgotten which verified_identifier they were in the past, and the  
IdP can ask the user to confirm they want to use a different  
verified_identifer then the one they have previously used.
+ works with OpenID 1.1 as even though a 1.1 RP will send the  
delegate, a 2.0 IdP will send back the verified_identifier.

NOTE: The delegate tag is just a token that the user sticks into  
their HTML so that the IdP knows the user controls that URL. If the  
IdP controls the URL, then the delegate tag is not needed.

___
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: XRI canonical id question

2006-10-10 Thread Drummond Reed
Johannes Ernst wrote:
 Drummond:
 
 The current auth draft says in section 11.4:
 If the Verified Identifier is an XRI, the discovered CanonicalID 
 field from the XRD SHOULD be used as a key for local storage of 
 information about the End User.
 
 Is there ever a scenario where the identifier is disassociated from the 
 CanonicalID? I was wondering whether there is a potential security hole?
 
 [I simply don't know, so I'm asking you ;-) ]
 
 
Martin Atkins wrote:

I'm pretty sure that i-numbers are never re-assigned. That's a pretty 
fundamental design principle for XRI, as I understand it.

Exactly. It's important to note that while XRI syntax and resolution enable
this on a technical level, it's still ultimately a policy that has to be
enforced at a registry level. This has always been true of URNs -- as the
IETF noted at the conclusion of its URN effort, persistence is an
operational characteristic of an identifier, not purely a technical
characteristic. (For more on persistent identifiers, I recommend
http://www.nla.gov.au/padi/topics/36.html). 

RPs should ideally be displaying the entered i-name but using the 
i-number as the primary key. Of course, this does have the possibility 
that in future the display name may be wrong, but since the RP should be 
storing both it will be able to detect during auth that the two have 
become detached and create a new conceptual user, probably 
disassociating the i-name from the old one in the process.

Right on the money. I would go further and recommend that an RP not even
store the i-name, just the i-number and a user's preferred display name.
That way the i-name becomes really just a convenient way for the user to
give the RP their i-number (CanonicalID).

This does pose a problem to humans in that the RP will be displaying an 
incorrect i-name until the new owner tries to authenticate with the same 
RP, which may never happen.

Again, this is why I recommend RPs don't even store the i-name, but instead
store their own display name for the user. The display name and the i-number
(CanonicalID) never need to change, whereas an i-name may be reassigned.

=Drummond 

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


RE: Consolidated Delegate Proposal

2006-10-10 Thread Drummond Reed
 Martin wrote:
 I'm surprised that our resident privacy advocates aren't making a  
 bigger
 deal out of this. (If the privacy advocates have no problem then I'll
 let this go, since this isn't a use case I feel particularly strongly
 about myself.)

Dick wrote:

I was supportive of keeping the delegate from the IdP until I  
realized that the delegation was public knowledge and could not be  
hidden from the IdP.

The same argument convinced me, too. If public XRDS documents are what we're
using to provide user control of identifier synonyms and thus provide
identifier portability -- which is the clearest and cleanest approach we've
seen -- then the best thing we can do from a privacy perspective is not
mislead users that they are protecting their privacy by using a public
OpenID identifier and a private identifier with their IdP.

=Drummond  

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


RE: XRI canonical id question

2006-10-10 Thread Drummond Reed
 On 10-Oct-06, at 11:00 AM, Drummond Reed wrote:
 
 Again, this is why I recommend RPs don't even store the i-name, but  
 instead
 store their own display name for the user. The display name and the  
 i-number
 (CanonicalID) never need to change, whereas an i-name may be  
 reassigned.

Dick wrote:

why would an i-name be reassigned?

Just like a domain name, an i-name registration can lapse and be returned
back into the name pool, where it can be registered by a different
registrant.

why would an i-number not be reassigned?

I-numbers are functionally URNs. They are assigned once by a registry
(globally or at any level of delegation) and never reassigned. Even if the
registration lapses, it can only be renewed by the original registrant (or
their trustee).

I-numbers are one of the most unique features of XRI registries. See the
XDI.org Global Services Specifications at http://gss.xdi.org for much more
than you ever wanted to know about the policies around persistent identifier
management. Good lawyers took as many years as the technologists to come up
with this stuff ;-)

who owns the i-number?

The original registrant - forever. Even if they die, they can appoint one or
more trustees to continue to own/manage the registration.

I thought that who is authorative for an i-name was managed by a  
registry that was separate from the i-broker, and that mechanism  
provided the separation of identifier management from IdP.

It does. The same way domain name registrations are portable from one DNS
registrar to another, global i-name and i-number registration are portable
across IdPs (in XDI.org XRI infrastructure they are called i-brokers).

The role of the IdP/i-broker, like the role of a DNS registrar, is to
perform transactions with the registry on the registrant's behalf, i.e.,
register, update, delete, and transfer registrations.

=Drummond 

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


RE: XRI canonical id question

2006-10-10 Thread Drummond Reed
You got it. The irony is that as simple are compared to i-names, i-numbers
are the real anchor of persistent identity and identifier portability.

It's like IP addresses and DNS names: the former do all the work, and the
latter get all the visibility.

=Drummond 

-Original Message-
From: Dick Hardt [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, October 10, 2006 12:06 PM
To: Drummond Reed
Cc: 'Martin Atkins'; specs@openid.net
Subject: Re: XRI canonical id question

Ok, I think I get the justification now:

i-numbers are in unlimited supply and have no inherent value except  
as a handle, so they don't need to be managed the same way

i-names are a namespace and hence are limited, and have value to  
humans, so there is value in separating the handle from the human  
readable part

Am I getting it?

-- Dick

On 10-Oct-06, at 11:55 AM, Drummond Reed wrote:

 On 10-Oct-06, at 11:00 AM, Drummond Reed wrote:

 Again, this is why I recommend RPs don't even store the i-name, but
 instead
 store their own display name for the user. The display name and the
 i-number
 (CanonicalID) never need to change, whereas an i-name may be
 reassigned.

 Dick wrote:

 why would an i-name be reassigned?

 Just like a domain name, an i-name registration can lapse and be  
 returned
 back into the name pool, where it can be registered by a different
 registrant.

 why would an i-number not be reassigned?

 I-numbers are functionally URNs. They are assigned once by a registry
 (globally or at any level of delegation) and never reassigned. Even  
 if the
 registration lapses, it can only be renewed by the original  
 registrant (or
 their trustee).

 I-numbers are one of the most unique features of XRI registries.  
 See the
 XDI.org Global Services Specifications at http://gss.xdi.org for  
 much more
 than you ever wanted to know about the policies around persistent  
 identifier
 management. Good lawyers took as many years as the technologists to  
 come up
 with this stuff ;-)

 who owns the i-number?

 The original registrant - forever. Even if they die, they can  
 appoint one or
 more trustees to continue to own/manage the registration.

 I thought that who is authorative for an i-name was managed by a
 registry that was separate from the i-broker, and that mechanism
 provided the separation of identifier management from IdP.

 It does. The same way domain name registrations are portable from  
 one DNS
 registrar to another, global i-name and i-number registration are  
 portable
 across IdPs (in XDI.org XRI infrastructure they are called i-brokers).

 The role of the IdP/i-broker, like the role of a DNS registrar, is to
 perform transactions with the registry on the registrant's behalf,  
 i.e.,
 register, update, delete, and transfer registrations.

 =Drummond




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


RE: Consolidated Delegate Proposal

2006-10-10 Thread Drummond Reed
 Drummond wrote:

 If we've got it wrong there, and there is a way to do all of this  
 with one
 parameter, by all means do explain and we can finally close this  
 issue.

Dick wrote:

I thought I did explain it. :-)

I will explain it again in a separate post.

Better still, if you could add it to the end of
http://www.lifewiki.net/openid/ConsolidatedDelegationProposal and explain
how the same motivations and use cases currently covered there (using two
identifier parameters) can be satisfied just using openid.identity, that
would help use consider everything in one place.

Thanks,

=Drummond 
 

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


RE: Consolidated Delegate Proposal

2006-10-10 Thread Drummond Reed
 Drummond wrote:

 Better still, if you could add it to the end of
 http://www.lifewiki.net/openid/ConsolidatedDelegationProposal and  
 explain
 how the same motivations and use cases currently covered there  
 (using two
 identifier parameters) can be satisfied just using openid.identity,  
 that
 would help use consider everything in one place.

Dick wrote:

As I ponder this, I don't think that Proposal is a good starting  
point, but I will elaborate more then I did last time and take a  
different approach on explaining it.

I understand if you don't want to use that proposal as a starting point. I'm
just advocating that if you have a new proposal, putting it on the wiki and
explaining it in a similar fashion so we can compare the two proposals
side-by-side. I'm a big fan of wikis over email when it comes to closing
issues (see http://wiki.oasis-open.org/xri/Xri2Cd02/ResWorkingDraft11 for an
example of what we've been through to close (almost) all the issues for XRI
Resolution 2.0 Working Draft 11 over the last two months).

Unfortunately it will not go out until later tonight or sometime  
tomorrow as I have a string of meetings coming up now.

Understood. I myself have meetings all day Wed/Thur, so I won't be able to
spend as much time on this in that timeframe either.

=Drummond 

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


RE: Consolidated Delegate Proposal

2006-10-10 Thread Drummond Reed
 On 10/10/06, Dick Hardt wrote:
 [openid.rpuserid is the identifier] that the user gave the RP?

 Josh Hoyt wrote:
 For URL identifiers, it is the supplied identifer, normalized, after
 following redirects. In essence, it's the user's chosen identifier.

 For XRI identifers, it's the canonical ID (i-number).

Dick Hardt wrote:

This comment led me to want to make sure I understand the  
requirements of XRI.

Q: why would the RP not want the i-name to come back rather then the  
i-number?

The i-number can be derived from the i-name. The i-name is what is  
user visible. The IdP will make sure the i-name the user is  
presenting resolves to the i-number the user has presented in the past.

Am I missing something?

Since the RP has to do discovery on the i-name, the RP already has the
i-number (CanonicalID). Further, as explained in previous threads, the
CanonicalID is the primary key the RP wants to store for the user, not the
i-name, because the i-number is forever while the i-name could change.

The RP is also motivated to send the i-number to the IdP for the same reason
that the RP is motivated to send the delegate URL (if available): to
increase performance by saving the IdP from having to re-resolve the i-name
(in the XRI case) or original URL (in the URL case).

Lastly, in the case where the identifier-the-RP-stores and the
identifier-the-IdP-stores are different, if the RP has already discovered
the latter, then the RP can be stateless by sending both to the IdP, knowing
it will receive both back in the response. If the RP can only send one
identifier to the IdP, it's stuck with a dilemma:

* If the RP sends the identifier-the-RP-stores, then it forces the IdP to
redo discovery, slowing performance.
* If the RP sends the identifier-the-IdP-stores, then the RP cannot be
stateless because it has to maintain a mapping between the
identifier-the-RP-stores and the identifier-the-IdP-stores.

In summary it boils down to this:

* If the identifier-the-RP-stores and the identifier-the-IdP-stores are both
the same, everything works fine with one identifier parameter,
openid.identity.

* However if the identifier-the-RP-stores and the identifier-the-IdP-stores
are different, several efficiencies and optimizations are possible by
enabling protocol messages to send and receive both the
identifier-the-RP-stores (openid.rpuserid) and the identifier-the-IdP-stores
(openid.identity) That's the proposal currently summarized at
http://www.lifewiki.net/openid/ConsolidatedDelegationProposal. 

=Drummond 


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


RE: Consolidated Delegate Proposal

2006-10-09 Thread Drummond Reed
Maybe I misunderstood the directed identity protocol. Section 4.2.3.1 of
Draft 9 says:

*** EXCERPT ***

4.2.3.1.  IdP Identifiers

If the entered Identifier is an IdP Identifier, the OpenID information is
contained in a service element with the following information:

* An xrd:Type tag whose text content is http://openid.net/server/2.0;
* An xrd:URI tag whose text content is The IdP Endpoint URL

*** END ***

So in the discovery phase what the RP should find is an xrd:Type tag of
http://openid.net/server/2.0;. That's what I meant.

Am I missing something?

=Drummond 

-Original Message-
From: Recordon, David [mailto:[EMAIL PROTECTED] 
Sent: Monday, October 09, 2006 9:34 AM
To: Drummond Reed; specs@openid.net
Subject: RE: Consolidated Delegate Proposal

Ok, that makes it more clear.

I think this line was part of what was throwing me, If Claimed
Identifier is EITHER a URL or XRI that maps to a directed identity
server (http://openid.net/server/2.0), the values are: since in the
discovery phase it should be finding the type of identifier_select.

--David 

-Original Message-
From: Drummond Reed [mailto:[EMAIL PROTECTED] 
Sent: Monday, October 09, 2006 1:20 AM
To: Recordon, David; specs@openid.net
Subject: RE: Consolidated Delegate Proposal

David Recordon wrote:

Read through it
(http://www.lifewiki.net/openid/ConsolidatedDelegationProposal),
and I'm liking how it really clears up delegation.  A few questions:

1) In case 1, is what the user typed in ever sent from the RP to the 
IdP?  What if it is an OpenID Auth 2.0 IdP, but the user entered their 
identifier on the RP?  Or in the case where the IdP supports multiple 
identifiers for the user, shouldn't the RP send what the user entered 
so the user doesn't have to choose it again at their IdP?

Case 1 is the directed identity case. The RP *could* send what the user
types in at the RP (the identifier for the IdP's directed identity
server), but since the RP knows (from the OpenID service type) that this
is an anonymous login, and thus that the RP needs to get
openid.rd_user_id *back* from the IdP, it seemed better for the RP not
to send anything. This way you never break the rule that the IdP never
changes any of the identifier parameters than an RP sends it.

2) This may also be part of my first question, but why is there such a 
delta between case 1 and cases 2 and 3?  How does the RP know to use 
case 1 versus case 2, they seem quite similar in their explanation?

Again, Case 1 is the directed identity case, that's why it's so unusual.
The way the RP differentiates between case 1 and cases 2/3/4/5 is that
only in case 1 is the value Type attribute in the OpenID service
endpoint http://openid.net/identifier_select/2.0;.

I went back and rewrote the page to make this much clearer.

3) What is openid.display used for?

The complete explanation was in the latter part of
http://openid.net/pipermail/specs/2006-October/000278.html. But to make
the consolidated proposal easier to review, I added a Summary of
Motivations
section at the start and put a section at the end explaining the
motivation for openid.display. 

4) In the rules, don't you mean the IdP must return the value of the 
rp_user_id for the RP to key off of, not the value of identity?

Yes, sorry, this was unclear. What I meant was that since the RP must
ALWAYS send openid.identity, the RP could *ALWAYS* count on this in the
response.
However you're right that as far as a persistent key goes 

I think this is getting there, just either needs to be tightened up or 
the different flows better explained.

I think it just needed to be better explained. Also, Josh, note that
when I went back to edit this tonight, I found the parameter name
openid.rp_user_id was driving the wiki markup nuts. So I changed it to
just openid.rpuserid. Personally, I think this reads fine and
eliminates the awkward underscores. I hope you agree.

=Drummond 



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


RE: Delegation Proposal Amendment

2006-10-09 Thread Drummond Reed
Dick,

The persistent identifier I referred to in this thread was whatever
identifier the RP was going to persist (proposed to be called
openid.rpuserid on
http://www.lifewiki.net/openid/ConsolidatedDelegationProposal). This boils
down to:

* If Claimed Identifier = URL, then openid.rpuserid = URL
* If Claimed Identifier = XRI i-name (reassignable), then openid.rpuserid =
XRI i-number (CanonicalID - persistent).

Both are discoverable from the XRDS document once the RP has done discovery.
That's cases 2/3/4/5 on
http://www.lifewiki.net/openid/ConsolidatedDelegationProposal. 

Thus the only case where the RP does not have an identifier to persist is
the directed identity case (Case 1). In that case, the RP does not send
openid.rpuserid, but instead receives it back in the response from IdP. 

=Drummond 

-Original Message-
From: Dick Hardt [mailto:[EMAIL PROTECTED] 
Sent: Monday, October 09, 2006 2:21 PM
To: Drummond Reed
Cc: 'Josh Hoyt'; specs@openid.net
Subject: Re: Delegation Proposal Amendment

Drummond

How does the RP get a persistent identifier before it has called the  
IdP? The user could type anything into the form.

-- Dick

On 6-Oct-06, at 2:22 PM, Drummond Reed wrote:

 Josh,

 This is very cool. Adding openid.rp_user_id would give us an  
 unambigous way
 to represent what I called the RPI in my earlier message:

 IPI = IdP-Persistent-Identifier = openid.identity

 RPI = RP-Persistent-Identifier = openid.rp_user_id

 It doesn't address the third identifier, which I called UPI
 (User-Presented-Identifier -- the one the user typed in at the RP),  
 but
 let's leave that aside for now.

 So as I understand it, the rules would be:

 * ON THE RP SIDE *

 The RP ALWAYS does discovery on UPI. Then it applies these tests:

 1) If UPI maps to a directed identity server
 (Typehttp://openid.net/server/2.0/Type), then:
   openid.rp_user_id = [empty]
   openid.identity = http://openid.net/identifier_select/2.0;

 2) If UPI is an XRI that maps to a CanonicalID AND there is no
 openid:delegate element in the XRD, then:
   openid.rp_user_id = CanonicalID
   openid.identity = CanonicalID

 3) If UPI is an XRI that maps to a CanonicalID AND to an IPI (via the
 openid:delegate element in the XRD), then:
   openid.rp_user_id = CanonicalID
   openid.identity = IPI

 4) If UPI is a URL that maps to an IPI (via the openid:delegate  
 element in
 the XRD), then:
   openid.rp_user_id = UPI
   openid.identity = IPI

 5) Else:
   openid.rp_user_id = UPI
   openid.identity = UPI


 * ON THE IDP SIDE *

 6) IdP ALWAYS keys on the value of openid.identity.

 7) IdP ALWAYS returns the same value of openid.identity that the RP  
 sent (so
 the RP can always key off this value in the response).

 8) IdP ALWAYS returns the value of openid.rp_user_id UNLESS it was  
 empty, in
 which case see rule 9a below.

 9) IdP MAY or MAY NOT do discovery. The rules are:

   a) If openid.identity = http://openid.net/identifier_select/2.0;,
 then IdP prompts User for UPI (or detects cookie, etc.). If UPI !=  
 IPI, then
 IdP does discovery on UPI to get mapping to IPI. IdP authenticates  
 against
 IPI, but at that point allows user to select the RPI (or generates  
 for the
 user). IdP returns:
   openid.rp_user_id = user-selected or IdP-generated RPI
   openid.identity = http://openid.net/identifier_select/2.0;

   b) If openid.identity = UPI that IdP does not recognize, then IdP
 does discovery on UPI to get mapping to IPI. After authentication  
 against
 IPI, IdP returns:
   openid.rp_user_id = UPI
   openid.identity = UPI

   c) If openid.identity = IPI, IdP does not need to do discovery, but
 authenticates against IPI and returns:
   openid.rp_user_id = [value sent by RP]
   openid.identity = IPI

 *

 This all works wonderfully and covers all the use cases --  
 congratulations!

 Now, let me make a case for also making the third identifier -- the  
 UPI --
 explicit in the protocol. This addresses a specific usability issue  
 that
 arises due to the fact that XRIs support i-name/CanonicalID  
 separation,
 which URLs don't. However I believe it can also improve usability  
 for URLs.

 The motivation is that in cases 2 and 3 above, the  
 openid.rp_user_id that
 the RP passes to the IdP is going to be an CanonicalID, which is an
 i-number. This is a very ugly string like:

   =!F83.62B1.44F.2813 (that's my actual i-number)

 However the IdP only has the choice of openid.rp_user_id or  
 openid.identity
 from which to greet me to ask for my authentication credentials.  
 Since these
 will both be a CanonicalID, this leads to a greeting like:

   Hello =!F83.62B1.44F.2813. Please confirm that you want to login
   to YourFavoriteRP. [Allow Once] [Allow Always] [Cancel]

 All it takes to solve this problem is for the RP to pass the UPI in  
 the
 authentication request. Then the IdP can say:

   Hello

RE: Consolidated Delegate Proposal

2006-10-09 Thread Drummond Reed
Dick, 

As Josh explains in
http://openid.net/pipermail/specs/2006-October/000296.html, the primary
motivation for openid.display is when the user enters an i-name into the RP.
As Josh puts it:

Basically, =foo and =bar could both be tied to the same i-number. Doing
resolution on =foo and =bar will yield the same canonical id, which means
that they represent one logical entity. Drummond wants the display name to
tell the IdP *which* synonym the user entered at the RP so that the IdP can
present that same synonym in the UI, since the canonical id is both
the IdP user identifier and the RP user identifier, but is not
user-friendly (=!1234.1234.1234.1234)

It boils down to this: 

* If what the user enters at the RP is a URL, then there is at least one and
at most two identifiers involved -- the Claimed Identifier and an optional
Delegate Identifier.
* If what the user enters at the RP is an XRI, then there are at least two
and at most three identifiers involved -- the Display Name (i-name), the
Claimed Identifier (i-number -- CanonicalID), and an optional Delegate
Identifier (which is usually the same CanonicalID but does not have to be).

Thus openid.display gives IdPs who support XRIs the ability to echo back to
the user the i-name synonym they typed in at the RP, rather than by their
CanonicalID i-number, which they are about as likely to know as their IP
address.

If we decide that's totally unnecessary -- that it's always okay for an IdP
to just address an XRI user by an internal account name and not the i-name
synonym they used at the RP -- then we can drop openid.display.

=Drummond 

-Original Message-
From: Dick Hardt [mailto:[EMAIL PROTECTED] 
Sent: Monday, October 09, 2006 2:19 PM
To: Drummond Reed
Cc: 'Josh Hoyt'; 'Recordon, David'; specs@openid.net
Subject: Re: Consolidated Delegate Proposal

I have finally got up on this thread and don't see the value of the  
openid.display parameter.

The RP does not know who the user is when the user is using OpenID to  
login, since that is why the RP is using OpenID, to find out who the  
user is.

Having the user type in another parameter just lets the user see the  
same thing at the IdP. What's the point?

The user clearly knows they are at two different sites, and I think  
it is more important to have a consistent experience at the IdP  
across RPs then to have a consistent experience between the RP and  
the IdP.

The IdP must know who the user is in order to create a positive  
response back to the RP, so the IdP will already have some display  
values to show the user.

... so what am I missing?

-- Dick


On 9-Oct-06, at 10:56 AM, Drummond Reed wrote:

 Josh, your message arrived while I was writing my reply to David's.

 I agree completely that openid.display is primarily useful for i-name
 synonyms.

 You go on to say, For URIs, the display name *must* be the same as  
 the RP
 user identifier, because there is no other value is verifiable by  
 the IdP.

 I was proposing that openid.display be treated simply a string, so  
 neither
 an RP nor an IdP would ever never resolve it, verify it, use it as  
 key, etc.

 openid.display would default to openid.rpuserid if the RP didn't  
 send an
 openid.display value. And if openid.rpuserid was a CanonicalID,  
 then an RP
 SHOULD at least send the i-name as openid.display.

 However if the RP wanted to prompt a user for a short Display Name,  
 even if
 the User's Claimed Identifier was a URL, the RP *could* send this  
 Display
 Name to the IdP, and the IdP *could* display it so the user  
 experience was
 consistent across the two sites.

 For example:

 At RP site the prompts are:

 OpenID Identifier:
 Your Preferred Display Name:

 The user enters:

 OpenID Identifier: example.idp.com/some/long/URL
 Your Preferred Display Name: DSR

 The RP sends to IdP:

 openid.identity = http://example.idp.com/some/long/URL
 openid.rpuserid = http://example.idp.com/some/long/URL
 openid.display = DSR

 The IdP displays:

 Hello DSR. Do you want to login to YourFriendlyRP?
 Password: []
 [Accept Once] {Accept Always] [Cancel]


 =Drummond

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of  
 Josh Hoyt
 Sent: Monday, October 09, 2006 10:28 AM
 To: Recordon, David
 Cc: Drummond Reed; specs@openid.net
 Subject: Re: Consolidated Delegate Proposal

 On 10/9/06, Recordon, David [EMAIL PROTECTED] wrote:
 In terms of openid.display, shouldn't the IdP greet the user in  
 whatever
 manner it uses?  Thus if the user has an account on the IdP, the IdP
 should always greet the user in the same manner with it.  Seems like
 both a usability, phishing, and potential XSS issue if the IdP greets
 the user with a string from the RP.

 Am I just missing something there?

 The display name is only useful for XRI synonyms. Basically, =foo and
 =bar could both be tied to the same i-number. Doing resolution on =foo
 and =bar will yield the same canonical id, which

RE: [PROPOSAL] Separate Public Identifier from IdP Identifier

2006-10-06 Thread Drummond Reed
+1. Josh is right. Ultimately there are three identifiers involved in all
interactions between the User, the RP, and the IdP:

1) User-Presented-Identifier (UPI): the identifier entered by the User at
the RP.

2) RP-Persisted-Identifier (RPI): the identifier that will be persisted by
the RP in order to recognize the User when next the User returns.

3) IdP-Persisted-Identifier (IPI): the identifier persisted by the IdP
against which the IdP will authenticate the user.

Here's a simple analysis of how these are used during the different flows:

OPENID 1.X

1) User enters UPI
2) RP discovers IPI (if any -- otherwise UPI = IPI)
3) RP sends IPI to IdP
4) IdP authenticates against IPI
5) IdP responds with IPI

JOSH'S PROPOSED FLOW

1) User enters UPI
2) RP sends UPI to IdP
3) IdP discovers IPI (if any -- otherwise UPI = IPI)
4) IdP authenticates against IPI
5) IdP responds with UPI

OPENID 2.0 DIRECTED IDENTITY FLOW

1) User enters UPI (where UPI = identifier of directed identity server)
2) RP sends special UPI (http://openid.net/identifier_select/2.0;) to IdP
3) IdP discovers IPI
4) IdP authenticates against IPI
5) IdP responds with RPI

OPENID 2.0 XRI CANONICAL ID FLOW

1) User enters UPI (XRI i-name)
2) RP discovers RPI (XRI i-number = CanonicalID)
3) RP sends RPI to IdP
4) IdP authenticates against RPI (RPI = IPI)
5) IdP responds with RPI

*

On this basis, it seems the solution is for the protocol to clearly
recognize all three identifier types. This would:

a) Support all four flows above.
b) Enable RPs and IdPs to all do the right thing at the right time with the
right identifier
c) Eliminate confusion over which identifier is doing what in each flow.

So we would go from openid.identity, which is currently overloaded, to:

openid.identity = IPI
openid.persist = RPI
openid.display = UPI

Or whatever names everyone can agree on.

=Drummond 


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Josh Hoyt
Sent: Friday, October 06, 2006 10:34 AM
To: Martin Atkins
Cc: specs@openid.net
Subject: Re: [PROPOSAL] Separate Public Identifier from IdP Identifier

On 10/6/06, Martin Atkins [EMAIL PROTECTED] wrote:
 * The IdP returns a document naming its authentication endpoint (in the
 URI field) and a special anonymous token as openid:Token. openid:Token
 may be the same as the public identifier from the previous step, but
 this is not required.

Anonymous is not a good thing to call this. What IdP-driven identifier
selection does is let the IdP help the user choose an identifier. In
no way is the response any more anonymous than an identifier that was
typed in by the user.

It is true that one of the motivations for this feature is the great
improvement in the user experience for site-specific identifiers, but
the IdP could just as well return a cross-site identifier for the
user.

Sorry to go on about terminology, but I think it's important for
understanding what's really going on.

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: [PROPOSAL] Separate Public Identifier from IdP Identifier

2006-10-06 Thread Drummond Reed
+1 to Kevin's point here -- no second discovery step is needed with an XRI.

=Drummond 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Kevin Turner
Sent: Friday, October 06, 2006 1:58 PM
To: specs@openid.net
Subject: Re: [PROPOSAL] Separate Public Identifier from IdP Identifier

From http://www.lifewiki.net/openid/SeparateIdentifierFromIdPToken
(change #3):
 Impact on XRI-based auth:
 
 An XRI is, for this purpose, a URI that can be resolved into a URL at
 which we can do Yadis discovery. Once Yadis discovery begins, flow
 continues as in the original proposal, where openid:Token can be any
 URI.

It's unclear to me whether you intended this to be a change from the
current specification or not, but it is.  Yadis discovery on URLs
resolved from XRIs is considered redundant, as there's nothing about
Yadis discovery that can't be done while resolving the XRI.  Since Yadis
uses the XRI resolution response format, you even get to use the same
code.

So was it your intention to add an extra layer to discovery here, or
should the above section be reworded?


___
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] bare response / bare request

2006-10-06 Thread Drummond Reed
On Fri, 2006-10-06 at 16:34 -0700, Drummond Reed wrote:
 Let me play the dumb customer here and say:
 
 * A whole lot of real-world users would love OpenID-enabled bookmarks. 
 * A whole lot of websites would love to offer them.
 * A whole lot of IdPs would love to provide them.

Kevin Turner wrote:

Okay Customer, if both websites and IdPs would love it, is it okay if
it's something that websites + IdPs can layer on top of the core?  If
some sites chose not to, and the IdP said login bookmark not available
for this site, would that be okay?

I guess so. The test I would apply is: If the basic protocol makes it easy
to layer on -- in a fashion that will be intereoperable by all RPs and IdPs
that support it, then yes, it's okay to let it be layered on.

If the basic protocol makes it tricky to implement, and thus not likely to
be interoperable between the RPs and IdPs that want to do it, that's not
okay.

Does that help?

=Drummond 

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


Consolidated Delegate Proposal

2006-10-06 Thread Drummond Reed
At David's suggestion, to make it easier to follow, I've posted what I
believe is a consolidated delegate proposal at:

http://www.lifewiki.net/openid/ConsolidatedDelegationProposal

This incorporates Josh's original, Martin's, Josh's amendment, and my
amendment to Josh's. 

Josh and Martin, please look this over and either make changes or comment as
needed. It will be wonderful to finally close this issue.

=Drummond 


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


RE: Re[4]: [PROPOSAL] authentication age

2006-10-04 Thread Drummond Reed
+1 to one key takeaway from this whole thread: that the
marketing/evangelism/messaging around OpenID MUST be very careful to clearly
communicate, in Gabe's words, what it can and cannot do right now.
Especially when it comes to hard problems like authentication context and
circles of trust that SAML and Liberty Alliance have been cranking for 5+
years at. As long as we  communicated clearly so expectations aren't raised
and then not met then we should give OpenID the runway it needs to grow
into those problems, just like 802.11 started thin and grew to become
nearly ubiquitous.

=Drummond 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Gabe Wachob
Sent: Wednesday, October 04, 2006 9:09 PM
To: 'Chris Drake'
Cc: specs@openid.net
Subject: RE: Re[4]: [PROPOSAL] authentication age

Chris-
I don't mean to be pessimistic about OpenID *AT ALL* - I truly do
believe that OpenID *WILL* get to the point where its valuable for the Visas
of the world. I don't want to stall it for the other use cases that are
motivating the people who are currently involved - I think OpenID can
quickly evolve when needed. OpenID should be as lightweight as needed for
the use case - and I so I think OpenID is great where it is. 
Its just that we have to be clear what its trying to do today and
what it is NOT trying to do. I think we'll surprise some people (like you) -
but in the long run, the credibility will be there - I *KNOW* the folks who
are involved with OpenID are smart and know what it can and cannot do right
now. We just have to make sure that its being communicated clearly so
expectations aren't raised and then not met...

-Gabe

 -Original Message-
 From: Chris Drake [mailto:[EMAIL PROTECTED]
 Sent: Wednesday, October 04, 2006 9:00 PM
 To: Gabe Wachob
 Cc: 'Kevin Turner'; specs@openid.net
 Subject: Re[4]: [PROPOSAL] authentication age
 
 Hi Gabe,
 
 Beautifully worded, and (IMHO) an extremely valuable real-world
 opinion.  I too believe OpenID is currently a non-starter.  I have
 dual vested interests:  I want OpenID to succeed, *especially* for RPs
 like Visa, since my IdP makes money from supporting OpenID only when
 OpenID ends up getting used.  I also believe that an IdP (and mine in
 particular) is well suited for deploying secure technology (eg: two
 factor tokens).  If, aside from making OpenID actually *work* for the
 likes of Visa, we can build in the ability to provide a tangible
 *benefit* to Visa from using it (that is: allow visa to REQUIRE that a
 user has authenticate via two-factor means, to an accredited - i.e:
 explicitly trusted by Visa - IdP) then we've not only cemented the
 future of OpenID, we've gone an improved a pile of security problems
 along the way.
 
 Kind Regards,
 Chris Drake
 1id.com
 
 Thursday, October 5, 2006, 1:41:34 PM, you wrote:
 
 GW Chris-
 GW   As someone who has recently come from working in the financial
 GW sector (Visa), its clear that OpenID is NOT intended for
 authentication
 GW where the *relying party* cares about how the authentication is
 performed.
 
 GW   At places like Visa and for home banking, this means that OpenID,
 GW without something more, is clearly a . These relying parties want
 GW to know exactly how their users are being authenticated because their
 GW business is all about risk management and creating business
 opportunities
 GW around very good knowledge of the risk profile of each transaction
 type.
 
 GW   That all being said, I believe it should be possible to layer on
 GW OpenID a form of IDP control such that a relying party can require a
 certain
 GW class or group of IDPs be used when presenting authentication
 assertions to
 GW them. The actual *policy* for how these IDPs are approved is probably
 GW orthogonal to the protocol spec, but secure identification of those
 IDPs
 GW (relative to some trust root, etc) could probably be made into an
 extension
 GW usable for those parties who want it.
 
 GW   My guess is that culturally, most people involved in OpenID have
 GW *not* been interested in addressing these concerns. However,
 expectations
 GW need to be better managed around these sort of relying-party cares
 GW scenarios, because its not obvious without actually reading the specs
 GW themselves...
 
 GW   -Gabe
 
  -Original Message-
  From: [EMAIL PROTECTED]
  [mailto:[EMAIL PROTECTED] On Behalf
  Of Chris Drake
  Sent: Wednesday, October 04, 2006 8:26 PM
  To: Kevin Turner
  Cc: specs@openid.net
  Subject: Re[2]: [PROPOSAL] authentication age
 
  Hi Kevin,
 
  Sounds like you're leaning towards a root authority for IdPs who can
  audit procedures and verify protection in order to sign the IdP's
  keys?
 
  Joe blogger doesn't care much about identity assertions from an IdP,
  but it's a reasonable bet to expect that a Bank might care...
 
  Kind Regards,
  Chris Drake
 
 
  ___
  specs mailing list
  

RE: openid.delegate explained.

2006-10-03 Thread Drummond Reed
Brad, thanks much for posting this. Having spent a ton of time on identifier
abstraction -- largely for the benefit of identifier portability -- I have
enormous respect for this feature.

So I am committed to being super-careful we don't break it just by renaming
it.

My proposal was limited to just that: renaming to solve the semantics
problem. (Ironically, I even understand how it first got the name
delegation. I doubt you or anyone else anticipated the context into which
that term would be thrust as OpenID grew, and thus the semantic clash that
would arise.)

Josh's proposal does affect how the feature actually works, and he's posted
separately about that. I agree we should be very careful to make sure any
substantive changes don't accidentally break the feature.

=Drummond 


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Brad Fitzpatrick
Sent: Tuesday, October 03, 2006 11:59 AM
To: specs@openid.net
Subject: openid.delegate explained.

I don't care what openid.delegate is renamed to.  But I feel strongly
it has to survive ... I think it's one of the most important things to
OpenID, just not well understood.

Let me walk through how it works

  * User Brad currently uses livejournal.com as his IdP

  * Brad doesn't want his LJ to be his canonical identifier because

  a) he has a better one, under his control (bradfitz.com),
 he's just too lazy or incapable of running an IdP there.

  b) he doesn't trust that LJ will stay around forever, or it
 might become evil, stop supporting OpenID, or maybe
 he might want to switch to a better IdP in the future.

  * So Brad gives RPs his bradfitz.com identifier.

  * RPs discover that bradfitz.com's IdP is LiveJournal.com, but
LiveJournal.com knows jack shit about bradfitz.com ... and
perhaps Brad doesn't trust LJ to know about bradfitz.com ...
or fears LJ might charge more to use that feature.  etc.

In summary, the most important thing is I can change my $4/year
identifier's IdP every day without informing anybody or making deals with
IdPs, AND IT DOESN'T BREAK MY IDENTITY EVERYWHERE.  All those sites that
thought I was bradfitz.com still think I'm bradfitz.com ... it's just a
different IdP asserting that.

Not to mention I can still avoid running my own IdP, adding to the
bootstrappability of all this ... because I imagine a lot of people will
want vanity-plate identifiers (well, never as cool as =BradFitz !) and
getting those early dorks in is important too, but not as important as
disconnecting an IdP from an identifier.  If a given identifier can only
be asserted by one IdP, we have lock-in, and people either don't change
IdPs, or change and break their identifiers.

So openid.delegate is like cellphone number portability.

I urge everybody not to accidentally break this while renaming it.

- Brad



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

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