Service Key Discovery 1.0

Tue Jan 22 15:44:09 UTC 2008

At some point, we have to draw a line between the "simple" and "enhanced" solutions. There is baggage around XRI-related technologies, but it doesn't make sense to keep inventing new things just because people refuse to give it a chance.

OpenID provides a simple way using HTTP requests. But once your needs are more complex than what 2.0 offers, looking at existing technologies is a better idea than keep inventing new ways of conducting business over HTTP parameters. Eventually, we are going to reach insanely long URIs with all those extensions. I question whether PKI information belongs in OpenID redirections.

The focus should be on XRDS as a discovery document. No matter how you feel about XRI, XRDS is part of OpenID 2.0, and not just the few elements mentioned by the spec, but the whole thing. OpenID points to XRI Resolution 2.0 as the sole authority on parsing an XRDS document. So you already have all this in OpenID. While many developers may choose to ignore the full XRDS format, their code will not be compliance with OpenID 2.0 is they do that.

EHL

-----Original Message-----
From: specs-bounces at openid.net [mailto:specs-bounces at openid.net] On Behalf Of Peter Davis
Sent: Tuesday, January 22, 2008 10:38 AM
To: Hans Granqvist
Cc: specs at openid.net
Subject: Re: Service Key Discovery 1.0

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

_______________________________________________
specs mailing list
specs at openid.net
http://openid.net/mailman/listinfo/specs