Draft OpenID v.Next Discovery working group charter

John Bradley john.bradley at wingaa.com
Thu Apr 15 18:53:42 UTC 2010


It may be true that all XRI is the work of the devil, leading us down a dark path to our doom.  
We get it!

The question is do we want to explore the possibility of claimed ID portability for other identifier types.

You seem to have a number of ideas and proposal for doing that with DNS authority identifiers.

Do you consider allowing the user to maintain control of the identifier if there IdP terminates service an important feature for the WG to consider?

Your feedback on IRI support is also welcomed.

John B.

On 2010-04-15, at 2:24 PM, Phillip Hallam-Baker wrote:

> 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