Which vocabulary would you suggest we use?

The Identity Gang, IETF, OASIS, Liberty, InfoCard?

btw: Philip, perhaps you can configure your GoodLink Wireless  
Handheld to send messages in plain text? ;-)

On 13-Oct-06, at 7:35 AM, Hallam-Baker, Phillip wrote:

> There is an established vocabulary, it should be used.
>
> Sent from my GoodLink Wireless Handheld (www.good.com)
>
>  -----Original Message-----
> From:   Recordon, David [mailto:[EMAIL PROTECTED]
> Sent:   Thursday, October 12, 2006 09:04 PM Pacific Standard Time
> To:     Gabe Wachob; Graves, Michael; specs@openid.net
> Subject:        RE: Delegation discussion summary
>
> I'd have to agree with Gabe about this, let's get it done! :)
>
>
>  -----Original Message-----
> From:   Gabe Wachob [mailto:[EMAIL PROTECTED]
> Sent:   Thursday, October 12, 2006 05:43 PM Pacific Standard Time
> To:     Graves, Michael; specs@openid.net
> Subject:        RE: Delegation discussion summary
>
> *If* we are going to open up the terminology discussion, for me the  
> terms
> "authenticating party" (formerly the "IDP") and "accepting  
> party" (formerly
> the "relying party") seem more descriptive.  The authenticating  
> party issues
> authentication assertions in the form of special HTTP request/ 
> responses with
> the other party, who then accepts these assertions and decides  
> whether or
> not they are good enough to let a user do something.
>
> As far as Dick's terminology, I'm not sure how "membersite" makes  
> sense
> here. Perhaps it's a matter of history or perspective that I  
> haven't been
> enlightened on.
>
> In any case, I'd rather get openid 2.0 out sooner than have a long
> discussion on terminology, so I won't push this any further unless  
> someone
> else really thinks its valuable.
>
>         Gabe
>
> > -----Original Message-----
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]  
> On Behalf
> > Of Graves, Michael
> > Sent: Thursday, October 12, 2006 5:00 PM
> > To: specs@openid.net
> > Subject: RE: Delegation discussion summary
> >
> > Josh, et al,
> >
> > I believe the first of your options --  "Both portable and IdP- 
> specific
> > identifiers" -- is the superior choice here. It preserves OpenID 1
> > semantics, and unambiguously makes room for portable identifiers. I
> > don't see the added burden carried by relying party code for this  
> option
> > viz. portable identifiers only as being significant. Recommend we
> > proceed with the "both" strategy.
> >
> > Also, this may be throwing a wrench in the gears here, but I'd  
> like to
> > toss in the idea of using this point in time to pivot on our  
> terminology
> > and look at adopting Dick Hardt's terminology here. Portable  
> identifiers
> > are a powerful upgrade in and of themselves, and get us off the "IDP
> > lock-in" hook that I've been hung up with customers on now a couple
> > times. But as we move away from explicit IdP-specific URLs as the  
> only
> > identifier, I think that the Sxip "homesite" model becomes more
> > important to consider as well. I very much like the idea of  
> entiring in
> > my "homesite" URL at a participating "membersite" (OpenID relying
> > party), say "http://myidmanager.com"; and during the authentication
> > process, being able to choose from one of n available personae  
> managed
> > for me by myidmanager.com. So my "final" identifier may be
> > "http://myidmanager.com/73648729"; or even "http:// 
> graves.isnuts.com".
> >
> > I won't delve into where we are with respect to that capability  
> here,
> > but want to suggest that maybe as we move to OpenID 2.0, and now  
> offer
> > portable IDs (as well as run-time chosen IDs selected at auth- 
> time?), we
> > may be wise to just make the jump to using "homesite" and  
> "membersite"
> > across the board, rather than "IdP" and "relying party", both of  
> which
> > are technically problematic for our framework.
> >
> > Anyway, that's a bit off topic, but something to consider.
> >
> > In any case, the "both" option below gets my vote.
> >
> > Good work Josh!
> >
> > -Mike
> >
> >
> > -----Original Message-----
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> > Behalf Of Josh Hoyt
> > Sent: Thursday, October 12, 2006 12:29 PM
> > To: specs@openid.net
> > Subject: Delegation discussion summary
> >
> > Hello, list,
> >
> > I'm sure that another message in your inbox with "delegation" in the
> > title makes most of you cringe, so I'm sorry for that.I hope that  
> this
> > one gets us closer to resolving this issue.
> >
> > I have attempted to summarize the proposed delegation mechanisms, as
> > well as the currently-specified delegation mechanism in a single
> > document. I have glossed over some issues and left out some of the
> > discussion, but I hope that I captured most of the important stuff.
> > After reviewing the discussion, I think that we are actually pretty
> > close to consensus on a course of action.
> >
> > I have added one new thing in this write-up, which is that I have
> > started calling "delegation" "portable identifier support", which  
> gives
> > rise to the term "portable identifier" for what is currently  
> called a
> > "delegated identifier." I think that this terminology is a little  
> easier
> > to understand and less loaded than calling it "delegation."
> >
> > My write-up follows.
> >
> > Josh
> >
> > OpenID portable identifier support
> > ##################################
> >
> > Portable identifier support allows an IdP to do authentication  
> for an
> > identifier that was not issued by that IdP. It has two motivating  
> use
> > cases [1]_:
> >
> >   * allow users to use any identifier with any IdP
> >
> >   * allow users to move an identifier between IdPs (prevent 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 = http://my.idp.specific.url/
> >   openid.portable = http://my.portable.url/
> >
> > The relying party is still responsible for checking to make sure  
> that
> > the IdP-specific identifier that is returned matches what is  
> discovered
> > from the portable identifier, but since it is included in the
> > authentication response, it is not necessary for the relying  
> party to
> > maintain this state, and an authentication response is meaningful
> > without the context of the request.
> >
> > The messages in this proposal are very explicit about what is  
> going on.
> > The only way in which this differs from OpenID 1 is that the  
> portable
> > identifier is also included in the response. The meaning of the
> > "openid.identity" parameter is identical to its meaning in the  
> OpenID 1
> > protocol (the IdP-specific identifier).
> >
> >
> > Portable identifier only
> > ------------------------
> >
> > Include only the portable identifier in the request and response  
> ([6]_
> > and [7]_)::
> >
> >   openid.identity = http://my.portable.url/
> >
> > In this proposal, the relying party does not use the IdP-specific  
> fields
> > that are available during discovery. The IdP must do discovery on  
> the
> > supplied identifier to determine what IdP-specific identifier has  
> been
> > specified.
> >
> > This proposal simplifies relying party behavior. The messages  
> that are
> > passed have an obvious meaning and are easy to verify. The  
> meaning of
> > the "openid.identity" parameter is different from its meaning in the
> > OpenID 1 protocol.
> >
> >
> > References
> > ==========
> >
> > .. [1] "openid.delegate explained."
> >
> >        Brad Fitzpatrick, 3 October 2006
> >
> >        http://openid.net/pipermail/specs/2006-October/000182.html
> >
> >
> >
> > .. [2] "OpenID Authentication 1.1"
> >
> >        David Recordon, Brad Fitzpatrick, May 2006
> >
> >        http://openid.net/specs/openid-authentication-1_1.html
> >
> >
> >
> > .. [3] "[PROPOSAL] bare response / bare request"
> >
> >        Dick Hardt, 30 September 2006
> >
> >        http://openid.net/pipermail/specs/2006-September/000142.html
> >
> >
> >
> > .. [4] "cachability of delegated identity URLs"
> >
> >        Brad Fitzpatrick, 8 June 2006
> >
> >        http://lists.danga.com/pipermail/yadis/2005-June/000676.html
> >
> >
> >
> > .. [5] "Delegation Proposal Amendment"
> >
> >        Josh Hoyt, 6 October 2006
> >
> >        http://openid.net/pipermail/specs/2006-October/000269.html
> >
> >
> >
> > .. [6] "Proposal: IdP-supported delegation"
> >
> >        Josh Hoyt, 4 September 2006
> >
> >        http://openid.net/pipermail/specs/2006-September/000002.html
> >
> >
> >
> > .. [7] "PROPOSAL: OpenID Authentication Flow and how delegate  
> fits in"
> >
> >        Dick Hardt, 9 October 2006
> >
> >        http://openid.net/pipermail/specs/2006-October/000310.html
> > _______________________________________________
> > specs mailing list
> > specs@openid.net
> > http://openid.net/mailman/listinfo/specs
> >
> > _______________________________________________
> > specs mailing list
> > specs@openid.net
> > http://openid.net/mailman/listinfo/specs
>
> _______________________________________________
> 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

Reply via email to