Draft OpenID v.Next Discovery working group charter

Phillip Hallam-Baker hallam at gmail.com
Thu Apr 15 18:24:35 UTC 2010


I do not see any evidence for the claim that XRI identifiers are any
more portable. All you have is to move from a domain where we have
experience of problems and how to solve them to a domain where we have
no experience whatsoever and the commercial sponsors of the scheme
purport that absence of evidence is evidence of absence.

On the issue of SSL certificates, I think that there is a way that we
can finesse that for the purposes of OpenID.

Consider first the fact that OpenID relying parties are not Web
browser clients, therefore they do not have to rely on Web browser
embedded trust roots or path semantics. So one solution would be to
simply stipulate that a self signed certificate is acceptable.

The ideal solution of course would be to authenticate the IdP using an
EV certificate, it is precisely the type of problem they were invented
to solve. But that is too expensive for most purposes. Ideally we
would want to have an assurance that the IdP was accountable, not just
that they owned a domain name. Clearly applications like trade are
going to require that level of trust.

Domain validated certs offer slightly more assurance than a
self-signed cert, but not enough to justify the cost for our
application. They are actually a good match as what we are trying to
authenticate is ownership of a domain name.

A free alternative that bridges the gap is a scheme I have been
working on in which we use X.509 certs at the SSL level and use the
DNS to authenticate the certificate. Ideally supported by DNSSEC at
the zone level and some meta-trust infrastructure above that level
(i,e. we do not have to force the ICANN root on everyone).

The way I would do this is through a PKIX extension that allows a cert
to say 'lookee here at this DNS record and you can validate a digest
of me', and then a new DNS RR to allow the digest algorithm and value
to be expressed.


It is more effort than just buying an SSL cert in, but it is also free.

On Thu, Apr 15, 2010 at 1:36 PM, John Bradley <john.bradley at wingaa.com> wrote:
> Nat,
>
> I think there are two issues.
>
> 1 identifier recycling.
>      eg if and email like identifier gets recycled the new owner should not be able to get access to the old owners accounts.
>      This is addressed by using a URI fragment in the claimed ID in openID 2.0
>
> 2 Identifier portability
>        At the moment only XRI supports a persistent claimed ID that can be moved between providers.
>        URI identifiers have limited portability based on delegation.
>
> I do think that understanding identifier portability is important.
>
> As openID moves up the LoA stack people will have more important and private information protected by there openID.
>
> On the other hand people have shown no inclination to pay for something they perceive as a free service.
>
> The iBrokers did not catch on.  Two years ago at ooTao we tried to interest DNS providers in bundling openID with domain names,  with not much success.
>
> I know chi.mp is trying to make a go of the latter.
>
> One of the problems the DNS folks have is providing SSL services.  People don't want to pay for something that provides them less security (if they understand) or is $70/year to cover the certificate.
>
> StartSSL or other certificate authorities would probably offer a bundle with a domain and hosting a personal XRD if there were a market.
>
> I understand the desire to make the claimed ID portable.   I just don't know that outside the people subscribed to this list anyone really wants it.
>
> It may actually be that the format of the identifier will become totally hidden by login buttons for the big 5 identity providers.
>
> Perhaps a design issue we should consider is "Are more then 2% of the users going to enter there identifier?"    If no then I suspect most RP will not be supporting multiple optional discovery formats for that <2%.
>
> What is the claimed_id format and how we discover the meta-data for that is important.
>
> Another question,  is Unicode / IRI important internationally.
>
> Currently Unicode names are only supported in XRI,   the behaviour for http: IRI is undefined.
> In principal it should work but fails in all the non XRI cases I have tested at RP.
>
> Is that something we need to cover in the identifier normalization rules?
>
> John B.
>
> On 2010-04-15, at 12:37 AM, Nat Sakimura wrote:
>
>> I suppose we need to define "OpenID identifiers" in the charter
>> proposal a little more.
>>
>> Specifically, I would like the discovery process to find a
>> non-reassignable identifier.
>> Otherwise, delegation would not work reliably etc.
>>
>> See: http://www.sakimura.org/en/modules/wordpress/identity-loss-with-openid-20/
>> for
>> some additional thought/discussion.
>>
>> =nat
>>
>> On Wed, Apr 14, 2010 at 4:30 AM, Mike Jones <Michael.Jones at microsoft.com> wrote:
>>> What follows is a draft charter for the OpenID v.Next Discovery working
>>> group.  This is one of 5 related charters for v.Next working groups to be
>>> formed to be discussed here, per my previous message.  Feedback is welcome,
>>> as are potential working group participants.
>>>
>>>
>>>
>>>                                                                 -- Mike
>>>
>>>
>>>
>>> (a)  Charter.
>>>
>>> (i)       WG name:  OpenID v.Next Discovery.
>>>
>>> (ii)      Purpose:  Produce a discovery specification or family of discovery
>>> specifications for OpenID v.Next that address the limitations and drawbacks
>>> present in the OpenID 2.0 discovery facilities that limit OpenID’s
>>> applicability, adoption, usability, privacy, and security.  Specific goals
>>> are:
>>>
>>> ·         enable discovery for OpenID identifiers, including those utilizing
>>> e-mail address syntax and those that are URLs,
>>>
>>> ·         enable discovery of features supported by OpenID v.Next OpenID
>>> Providers and Relying Parties,
>>>
>>> ·         enable discovery of attributes about OpenID v.Next OPs and RPs,
>>> including, but limited to visual logos and human-readable site names,
>>>
>>> ·         enable discovery supporting a spectrum of clients, including
>>> passive clients per current usage, thin active clients, and active clients
>>> with OP functionality,
>>>
>>> ·         enable discovery supporting authentication to and use of
>>> attributes by non-browser applications,
>>>
>>> ·         seamlessly integrate with and complement the other OpenID v.Next
>>> specifications.
>>>
>>>             Compatibility with OpenID 2.0 is an explicit non-goal for this
>>> work.
>>>
>>> (iii)     Scope:  Produce a next generation OpenID discovery specification
>>> or specifications, consistent with the purpose statement.
>>>
>>> (iv)     Proposed List of Specifications:  OpenID v.Next Discovery and
>>> possibly related specifications.
>>>
>>> (v)      Anticipated audience or users of the work:  Implementers of OpenID
>>> Providers, Relying Parties, Active Clients, and non-browser applications
>>> utilizing OpenID.
>>>
>>> (vi)     Language in which the WG will conduct business:  English.
>>>
>>> (vii)    Method of work:  E-mail discussions on the working group mailing
>>> list, working group conference calls, and face-to-face meetings at the
>>> Internet Identity Workshop and OpenID summits.
>>>
>>> (viii)  Basis for determining when the work of the WG is completed:  Work
>>> will not be deemed to be complete until there is a consensus that the
>>> resulting protocol specification or family of specifications fulfills the
>>> working group goals.  Additional proposed changes beyond that initial
>>> consensus will be evaluated on the basis of whether they increase or
>>> decrease consensus within the working group.  The work will be completed
>>> once it is apparent that maximal consensus on the draft has been achieved,
>>> consistent with the purpose and scope.
>>>
>>> (b)  Background Information.
>>>
>>> (i)       Related work being done in other WGs or organizations:  OpenID
>>> Authentication 2.0 and related specifications, including Yadis 1.0.  OAuth
>>> and OAuth WRAP.  XRDS, XRD, and WebFinger.
>>>
>>> (ii)      Proposers:
>>>
>>> Allen Tom, atom at yahoo-inc.com, Yahoo! (co-chair)
>>>
>>> Michael B. Jones, mbj at microsoft.com, Microsoft (co-chair)
>>>
>>> John Bradley, ve7jtb at ve7jtb.com, independent
>>>
>>> Additional proposers to be added here
>>>
>>> (iii)     Anticipated Contributions:  None.
>>>
>>>
>>>
>>> _______________________________________________
>>> specs mailing list
>>> specs at lists.openid.net
>>> http://lists.openid.net/mailman/listinfo/openid-specs
>>>
>>>
>>
>>
>>
>> --
>> Nat Sakimura (=nat)
>> http://www.sakimura.org/en/
>> http://twitter.com/_nat_en
>> _______________________________________________
>> specs mailing list
>> specs at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs
>
> _______________________________________________
> specs mailing list
> specs at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs
>



-- 
-- 
New Website: http://hallambaker.com/
View Quantum of Stupid podcasts, Tuesday and Thursday each week,
http://quantumofstupid.com/


More information about the specs mailing list