Draft OpenID v.Next Discovery working group charter
Phillip Hallam-Baker
hallam at gmail.com
Thu Apr 15 11:55:27 UTC 2010
It may be that we want to support Webfinger. But I disagree with the
example given.
In general as far as the charter goes, I think that it needs to have a
statement to the effect that the WG will liaise with the IETF and W3C
groups to arrive at a consistent architecture.
Let us imagine that Alice has a mail account 'alice at mail.com' and an
identity account 'alice' with idp.com.
Regardless of how we try to do the technology, either alice is going
to have to be telling sites that here idp is idp.com or mail.com is
going to have to do a referral to idp.com. And if alice wants her
email address to be visible to a site there is going to have to be
some attribute supplied by idp.com that links to alice.
Alice quite likely has that setup because she wants to control who can
contact her and avoid spam. So I don't think that there is any real
problem with Alice remembering her accounts as alice at mail.com and
alice at idp.com in that instance.
Now depending on what Alice's relation is to mail.com and idp.com it
might be desirable for the binding to be permanent or it may be
desirable for it to expressly not be permanent. If Alice is the owner
of the mail.com domain she probably wants the relationship to be as
permanent as that ownership - and will choose her idp accordingly. If
on the other hand Alice is an employee of mail.com we would ideally
want the assertion that alice at mail.com is her mail identifier to drop
as soon as it is withdrawn after her employment ends.
On Thu, Apr 15, 2010 at 3:19 AM, Paul E. Jones <paulej at packetizer.com> wrote:
> Phillip,
>
> I suggested use of SRV in my quest to find a friendly alternative to URLs as
> identifiers. I was then referred to Webfinger and, I must say, that has
> advantages:
> 1) As others pointed out, it's easier on scripting languages
> 2) SRV records tie an identifier to the domain, and my email address might
> be entirely separate from my identity provider
> 3) Using Webfinger builds value in a reusable web technology (and I've
> already found lots of uses for Webfinger)
>
> Perhaps we allow for use of both, but giving too many options leads to
> interoperability problems and makes the whole solution more complex. So,
> I'm not opposed to use of SRV records, but I would discourage it in favor of
> Webfinger.
>
> Paul
>
>> -----Original Message-----
>> From: openid-specs-bounces at lists.openid.net [mailto:openid-specs-
>> bounces at lists.openid.net] On Behalf Of Phillip Hallam-Baker
>> Sent: Tuesday, April 13, 2010 7:02 PM
>> To: Mike Jones
>> Cc: tech-comm at openid.net; specs at openid.net
>> Subject: Re: Draft OpenID v.Next Discovery working group charter
>>
>> I would like to add 'DNS' to the list of things we need to interoperate
>> with.
>>
>> The Internet has one naming system, the DNS. And email addresses and
>> URLs are built on DNS names.
>>
>> So if we are looking for a discovery mechanism for a protocol that
>> makes use of DNS names we should look to existing DNS features. As it
>> happens there is an existing DNS feature designed for generic service
>> discovery, the SRV record. It is supported in all commonly used DNS
>> servers including the Windows DNS server since Win2K.
>>
>> The reason this was not done in the past was that there were people
>> making arguments to the effect that the priority here needed to be
>> making it easy to set up identity providers. I don't find that
>> argument persuasive in the least. If a party cannot configure local
>> DNS for their name they are unlikely to be able to do what is
>> necessary to stand up a reliable IDP.
>>
>> We could consider other 'discovery' mechanisms in addition, but if we
>> do not support the use of DNS discovery we are not supporting the
>> Internet architecture.
>>
>>
>> On Tue, Apr 13, 2010 at 3:30 PM, 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
>> >
>> >
>>
>>
>>
>> --
>> --
>> New Website: http://hallambaker.com/
>> View Quantum of Stupid podcasts, Tuesday and Thursday each week,
>> http://quantumofstupid.com/
>> _______________________________________________
>> 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