Draft OpenID v.Next Discovery working group charter

Phillip Hallam-Baker hallam at gmail.com
Wed Apr 14 00:40:28 UTC 2010


That depends on the forum you are talking about.

If we are talking about IETF and W3C then anything that does not use
DNS for resolving services does not exist.

PHP supports SRV records as of PHP 5.
http://de3.php.net/manual/en/function.dns-get-record.php

The first versions of OpenID did not function at all well. One of the
main reasons for that was that the code was bending over backwards to
comply with buggy legacy code. The maintainers of scripting languages
are not deaf posts. If OpenID uses the internet architecture in a
principled way it is easy to approach them to ask for support.


The advantage of using DNS is that control of the DNS automatically
aligns with the right to control the DNS name (by definition). And so
when we are talking about who has the 'right' to make assertions about
Michael.Jones at microsoft.com they will automatically line up with the
Microsoft system administration without any third party intermediarry
being required.

So say we have a situation where there is some sort of federated
authentication service supported at microsoft.com, if we use DNS for
discovery we can automatically assume it is authoritative for
microsoft.com. So if I have a web site and I want to allow any
employee of microsoft to log in but only so long as they are a
microsoft employee, I can code that pretty easily with a rule that
says 'allow authenticated users from *@microsoft.com'.

At present I have to code round that type of requirement in really
unsatisfactory ways. I still have my VeriSign accounts at OASIS and
W3C even though I am no longer a VeriSign employee. Not a big issue in
that context, but rather more significant were they subscription
accounts at a content provider. It would be a really big win if MIT
could stand up an authentication service and staff/students could then
use their MIT athena accounts to access site licensed content directly
from the publisher's sites.


We cannot make any such assumption for backdoor discovery mechanisms
that are attempting to add semantics to other protocols. It is easy
enough to declare a mapping from name at example.com to
http://magic.example.com/moremagic/name but there really isn't
justification for asserting that control of the web server at a site
maps to responsibility for access control and authorization. In fact
at Microsoft it would assuredly not map that way because the web
server is being serviced by Akamai. And I am pretty sure that Akamai
are as reluctant to be responsible for authenticating Microsoft
employees as Microsoft are to allow them that control.

Using the Internet architecture in a principled manner allows a lot of
the complexities and ad-hoc workarounds that are currently required in
the spec to be avoided.


On Tue, Apr 13, 2010 at 7:23 PM, John Bradley <john.bradley at wingaa.com> wrote:
> The use of DNS has come up several times during the development of the XRD spec.
>
> A number of people argued that RP's implemented in PHP and other scripting languages don't have easy access to DNS SRV records.
>
> That group has pushed forward with LRDD at the IETF using a pure http: approach requiring only GET.
> http://tools.ietf.org/search/draft-hammer-discovery-04
>
> Things like Webfinger are profiles of LRDD with some application logic.
>
> I would not go as far as calling that anti internet architecture.
>
> There is still interest by some in the XRI TC at oasis to use DNS for resolving meta-data.
>
> By way of adoption the use of SRV records to resolve SAML meta-data has been close to zero.
>
> While not being personally opposed to having the debate again,  I suspect that DNS SRV records face an uphill battle.
>
> John B.
> On 2010-04-13, at 7:01 PM, Phillip Hallam-Baker wrote:
>
>> 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/
>
>



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