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 <[email protected]>
> 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, [email protected], Yahoo! (co-chair)
>>
>> Michael B. Jones, [email protected], Microsoft (co-chair)
>>
>> John Bradley, [email protected], independent
>>
>> Additional proposers to be added here
>>
>> (iii) Anticipated Contributions: None.
>>
>>
>>
>> _______________________________________________
>> specs mailing list
>> [email protected]
>> http://lists.openid.net/mailman/listinfo/openid-specs
>>
>>
>
>
>
> --
> Nat Sakimura (=nat)
> http://www.sakimura.org/en/
> http://twitter.com/_nat_en
> _______________________________________________
> specs mailing list
> [email protected]
> http://lists.openid.net/mailman/listinfo/openid-specs
_______________________________________________
specs mailing list
[email protected]
http://lists.openid.net/mailman/listinfo/openid-specs
