Service Key Discovery 1.0

[Peter Davis]

true enough.  However, there are design patterns (at least) from  
which one can apply to alternate representations (which is at the  
heart of, as you put it, 'key/value-pair way of doing what's desired' ).

=peterd

On Jan 22, 2008, at 10:27 AM, Hans Granqvist wrote:

> In essence, OpenID is a reaction to (perceived?) complexity, so  
> it's an
> uphill battle to reference SAML, XRI, or anything that touches on any
> W3 or OASIS standard effort relating to XML and security, really.
>
> So for OpenID, there has to be a simpler, "key/value-pair," way of
> doing what's desired, it seems.
>
> Hans
>
> On 1/21/08, Drummond Reed <drummond.reed at cordance.net> wrote:
>> 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: specs-bounces at openid.net [mailto:specs-bounces at openid.net]  
>>> On Behalf
>>> Of Peter Davis
>>> Sent: Monday, January 21, 2008 6:33 AM
>>> To: NISHITANI Masaki
>>> Cc: specs at 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 at openid.net
>>>> http://openid.net/mailman/listinfo/specs
>>>
>>> _______________________________________________
>>> 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
>>