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
Re: Consolidated Delegate Proposal
I think a i-name IdP would have a display name for each i-name and
show that consistent display name to the user. Why have the RP involved?
I think this delegate stuff is getting over complicated.
-- Dick
On 9-Oct-06, at 3:06 PM, Drummond Reed wrote:
> 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
RE: Consolidated Delegate Proposal
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
Re: Delegation Proposal Amendment
ok -- I get it now -- I think it is a bad name as it implies that this is the identifier that the RP persists across sessions really, it is the user identifier that the RP gets -- Dick On 9-Oct-06, at 2:38 PM, Drummond Reed wrote: > 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 >> (http://openid.net/server/2.0), 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
Re: Re[2]: [PROPOSAL] Separate Public Identifier from IdP Identifier
On 6-Oct-06, at 11:14 AM, Chris Drake wrote: > > An ***IdP*** can *initiate* the OpenID login with the RP using > openid:Token. > > How the User arrived at the RP with this token is not the concern of > the RP. (could be javascript, browser plugins, participating IdP > helper CGIs, or even the RP itself). The point is - the guts of the > authentication process remains unchanged and is backwards compatible, > but all the privacy-invasive components that live at the RP are thus > made *optional*. > > Simple as that. User only needs to remember and use one ID. User > only needs to type it one time each day (or however long they elect to > "stay logged on" for). Datamatching and privacy invasion are > eradicated. No need to key custom IdP anonymity URLs ever. Even > facilitates double-blind anonymous logins (with inclusion of a simple > RP nonce extension). Win-win-win. This is a great idea Chris! Since the protocol from the RP point of view is it receives a POST for the browser, how that gets started does not matter to the RP. Now all we need is a way for the IdP to know which URL to send the post. A couple options: 1) the RP includes the "login URL" in request messages to the IdP. The IdP saves it for allowing the user to bookmark. 2) the RP has the "login URL" somewhere easily discoverable by the IdP I would propose that both methods are supported. -- Dick ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: [VOTE] Rename openid.nonce to openid.response_nonce
+1 Allows us to easily have a request_nonce now or in the future and have clarity on what is what -- Dick On 9-Oct-06, at 2:19 PM, Recordon, David wrote: > Judging from a lack of responses, I'm guessing people don't really > care. > Is this a correct assessment? > > I'm +1 to this to add clarity, though also in the "don't really care" > boat at the same time. > > --David > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Recordon, David > Sent: Thursday, October 05, 2006 5:25 PM > To: specs@openid.net > Subject: [VOTE] Rename openid.nonce to openid.response_nonce > > Stemming from the proposal to add a request nonce, the idea to rename > the openid.nonce field to openid.response_nonce surfaced. Is this > something that we should do? > > Vote closes Tuesday the 10th at 3:30pm PST. Votes are +1 (in > support of > idea), 0 (abstain), or -1 (disagree). Traditionally a -1 vote, with > appropriate technical reasoning, will cause the vote as a whole to > fail. > In this case, I believe it will be best to make the decision tallying > all votes for and against unless a strong technical argument can be > made > for not renaming this parameter. > > --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
Re: Re[2]: [PROPOSAL] bare response / bare request
On 6-Oct-06, at 8:41 PM, Chris Drake wrote: > KT> 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. > > KT> Okay Customer, if both websites and IdPs would love it, is it > okay if > KT> it's something that websites + IdPs can layer on top of the > core? If > KT> some sites chose not to, and the IdP said "login bookmark not > available > KT> for this site", would that be okay? > > Technically - the only thing we need is a mechanism for the IdP to > find the RPs OpenID "bookmark entrance" - a hidden field in the > original login should be sufficient: IdP can then save this URL > in the users profile for them. Are you suggesting that the IdP can discover the bookmark_entrance by looking at an RP's site? -- Dick ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Delegation Proposal Amendment
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 > (http://openid.net/server/2.0), 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 thi
Re: [OT] our cookie expiration
On 9-Oct-06, at 1:12 AM, Josh Hoyt wrote: > On 10/8/06, Dick Hardt <[EMAIL PROTECTED]> wrote: >> [...] I would want the site to prompt for a password if I was >> doing something >> important. The only way for the IdP to know that is for the RP to >> tell it somehow -> auth_age request. > > This is only useful in conjunction with signed requests. A malicious > 3rd party could easily remove whatever parameter(s) in the request > that made the IdP prompt for the password. If the request is not > signed, it's a false sense of security at best. Not true. The malicious 3rd party can modify the request, but not the response. The response would contain the auth_age parameter as well, so the RP would know if the IdP was claiming to have performed the request. -- Dick ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
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 > (http://openid.net/server/2.0), 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 =drummond.reed. Please confirm that you want to login > to YourFavoriteRP. [Allow Once] [Allow Always] [Cancel] > > Better still, this functionality is not limited to XRIs. RPs can > apply it to > any User just by prompting the user for a preferred Display Name > along with > their OpenID identifier. Then the RP can send the Display Name as > the UPI > string so the IdP can call the user by the same name. For example: > > Hello Drummond. Please confirm that you want to login > to YourFavoriteRP. [Allow Once] [Allow Always] [Cancel] > > So this boils down to a simple proposed amendment to your amendment: > > PROPOSED AMENDMENT: Add a third optional parameter, openid.display, > the > value of which is the UPI. The rules governing its use: > > 1) If the RP DOES NOT send openid.display, it defaults to > openid.rp_user_id. > (And by your amendment, if RP does not send open
RE: [VOTE] Rename openid.nonce to openid.response_nonce
Judging from a lack of responses, I'm guessing people don't really care. Is this a correct assessment? I'm +1 to this to add clarity, though also in the "don't really care" boat at the same time. --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Recordon, David Sent: Thursday, October 05, 2006 5:25 PM To: specs@openid.net Subject: [VOTE] Rename openid.nonce to openid.response_nonce Stemming from the proposal to add a request nonce, the idea to rename the openid.nonce field to openid.response_nonce surfaced. Is this something that we should do? Vote closes Tuesday the 10th at 3:30pm PST. Votes are +1 (in support of idea), 0 (abstain), or -1 (disagree). Traditionally a -1 vote, with appropriate technical reasoning, will cause the vote as a whole to fail. In this case, I believe it will be best to make the decision tallying all votes for and against unless a strong technical argument can be made for not renaming this parameter. --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: 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 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)
>
> 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.
>
> Does that explanation help?
>
> 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: Consolidated Delegate Proposal
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 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)
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.
Does that explanation help?
Josh
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs
RE: Consolidated Delegate Proposal
No, you're not missing anything. That's what I thought at the outset too. And you may well be right -- the IdP can always use openid.identity to lookup the user's IdP account and retrieve an an internal display name from there. However I don't believe there's a security or phishing issue here -- the IdP would only echo the Display Name, if any, passed from the IdP. In other words, if the RP prompts for a Display Name, and the User enters one at the RP, then it's perfectly natural that the IdP can turn around and address the User by the same Display Name, since the IdP is authenticating the User's identity in the context of the RP. That doesn't mean the IdP can't also display it's own identifier(s) for the User if it wants (or other tokens that help prove to the User that they are not being phished). It's not just for i-names that openid.display is useful -- it's also handy for long URLs, where an RP is motivated to give the user a shorter display name to better control screen real estate. Anyway, those are the basic use cases. If there's not enough value in openid.display then we can drop it. openid.rpuserid is the meat of the proposal, because it enables a clean separation between the IdP-facing identifier (openid.identity) and the RP-facing-identifier (openid.rpuserid). =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 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: 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 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) 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. Does that explanation help? Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Consolidated Delegate Proposal
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 tag whose text content is "http://openid.net/server/2.0"; * An 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 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: 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 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: 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 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: [OT] our cookie expiration
On 10/8/06, Dick Hardt <[EMAIL PROTECTED]> wrote: > [...] I would want the site to prompt for a password if I was doing something > important. The only way for the IdP to know that is for the RP to > tell it somehow -> auth_age request. This is only useful in conjunction with signed requests. A malicious 3rd party could easily remove whatever parameter(s) in the request that made the IdP prompt for the password. If the request is not signed, it's a false sense of security at best. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
