proposal: RP display

Granqvist, Hans hgranqvist at verisign.com
Fri Sep 22 17:28:44 UTC 2006


+1 on keeping it as extension

My suggestion was: if some parts of an X.509 certificate (e.g., 
logo url, org names) can be useful in the openid message payload, 
then the protocol might as well specify how to send the cert 
itself, rather than expecting a party to extract certain parts 
of it (and possibly re-inventing signatures over those parts).

Hans


> -----Original Message-----
> From: Dick Hardt [mailto:dick at sxip.com] 
> Sent: Thursday, September 21, 2006 5:02 PM
> To: Granqvist, Hans
> Cc: Brad Fitzpatrick; specs at openid.net
> Subject: Re: proposal: RP display 
> 
> Hans, I'm not following what you are suggesting. Would you elaborate?
> 
> Regardless: I think Brad's suggestion that it belongs in an 
> extension is best. Moves the discussion to another venue, as 
> it opens up the question of if this functionality is part of 
> OpenID 2.0.
> 
> 
> On 21-Sep-06, at 9:50 AM, Granqvist, Hans wrote:
> 
> > Hey guys, I though openid was all about how PKI s*cks!  ;)
> >
> > Ok, so seriously, perhaps
> >
> >    'openid.certificate=[base64 encoded cert]'
> >
> > or even
> >
> >    'openid.certpath'  for 0..n certs
> >
> > would be more useful since the parties involved can then 
> decide what 
> > to do with 'plain' certs that contain no such extensions?
> >
> >
> >> -----Original Message-----
> >> From: specs-bounces at openid.net
> >> [mailto:specs-bounces at openid.net] On Behalf Of Dick Hardt
> >> Sent: Tuesday, September 19, 2006 5:21 PM
> >> To: Brad Fitzpatrick
> >> Cc: specs at openid.net
> >> Subject: Re: proposal: RP display
> >>
> >>
> >> A trusted CA would have signed the PayPal logo. As mentioned, 
> >> CardSpace is doing this, so OpenID would be able to follow 
> what works 
> >> (or does not)
> >>
> >> On 19-Sep-06, at 4:48 PM, Brad Fitzpatrick wrote:
> >>
> >>> Drawbacks:
> >>>    - false sense of security
> >>>
> >>> Can't badguy.com just crypto sign a PayPal logo hosted on
> >> badguy.com?
> >>>
> >>>
> >>>
> >>> On Mon, 18 Sep 2006, Dick Hardt wrote:
> >>>
> >>>> Problem:
> >>>>
> >>>> Identity of the RP is based on either the return_url or 
> trust_root.
> >>>> While these strings have the advantage that they are somewhat 
> >>>> verifiable as they are where the response will be sent, 
> neither of 
> >>>> these are user friendly. An organization name and/or a
> >> graphic can be
> >>>> more communicative. Additionally, when the user is wanting
> >> to review
> >>>> something that happened with an RP later on, the URL may 
> be quite 
> >>>> cryptic.
> >>>>
> >>>> The question arises, how does the IdP verify that the string or 
> >>>> graphic is really associated with the RP? Given that the
> >> user started
> >>>> off at the RP, and that somehow the user knows the RP is
> >> really the
> >>>> RP (a separate issue), then the user will be surprised by
> >> a graphic
> >>>> or string that is not related to the site the RP. In other
> >> words, if
> >>>> the user is being phished,  a cryptic URL is not going to
> >> provide the
> >>>> user with anything they have not already seen in the
> >> browser. An org
> >>>> name and/or graphic can be verified to belonging to the RP
> >> by a 3rd
> >>>> party, so the IdP can show the user if the displayed 
> info has been 
> >>>> verified or not.
> >>>>
> >>>> CardSpace is supporting signed graphics and I think is
> >> looking at the
> >>>> CA cert to check org name, so OpenID would be able to use
> >> a similar
> >>>> mechanism.
> >>>>
> >>>> Proposal:
> >>>> 	The additional of two optional parameters:
> >>>> 	= 'openid.logo_url - URL of either a signed or unsigned graphic 
> >>>> (size TBD)
> >>>> 	= 'openid.org_name' - organization name of RP
> >>>>
> >>>> Benefits:
> >>>> 	+ improved user experience
> >>>> 	+ mechanism for IdP to display verified data about RP to user
> >>>>
> >>>> Drawbacks:
> >>>> 	- additional work required for IdP to support, although
> >> IdP could
> >>>> ignore
> >>>>
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> specs mailing list
> >>>> specs at openid.net
> >>>> http://openid.net/mailman/listinfo/specs
> >>>>
> >>>>
> >>>
> >>>
> >>
> >> _______________________________________________
> >> specs mailing list
> >> specs at openid.net
> >> http://openid.net/mailman/listinfo/specs
> >>
> >>
> >
> >
> 
> 
> 



More information about the specs mailing list