specs Digest, Vol 28, Issue 22

John Bradley jbradley at mac.com
Mon Dec 22 23:49:07 UTC 2008


Breno,

I agree.  I recommended separating discovery into a separate doc for  
2.1.

There didn't seem to be support for the idea at the time,  perhaps  
circumstances have changed and the idea will be accepted now.

Regards
John Bradley
=jbradley

> Message: 2
> Date: Mon, 22 Dec 2008 11:07:52 -0800
> From: Breno de Medeiros <breno at google.com>
> Subject: Re: Proposal to form Discovery Working Group
> To: david at sixapart.com
> Cc: Brian Eaton <beaton at google.com>,	OpenID Specs Mailing List
> 	<specs at openid.net>,	Johannes Ernst <jernst at netmesh.us>
> Message-ID:
> 	<29fb00360812221107g5cd69346gfcac57575601f96f at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> For the time being, I would be happy if the 2.1 spec moved all the
> references to discovery to a second document.
>
> The first version of the separate document would just "clone" the
> current approach to discovery in the 2.0 spec. If the updated version
> that explains XRD discovery is available before the 2.1 WG completes
> its work, then it could refer to the new document, otherwise it could
> refer to the old document. In the case of pointing to old document, we
> probably should add an appendix noting that changes in discovery to
> support new use cases are coming, and pointers on how to manage the
> transition.
>
>
>
> On Mon, Dec 22, 2008 at 10:27 AM, David Recordon <drecordon at sixapart.com 
> > wrote:
>> Agreed with Breno here.  We're going to have to make a change to  
>> OpenID
>> discovery at some point over the next year as other groups finish  
>> their
>> evolutions of Yadis, XRDS, etc.  I like this being a separate WG  
>> since it
>> means that the core Auth spec can choose to move to using it at a  
>> later date
>> versus being tied up on it's development.
>>
>> --David
>>
>> On Dec 20, 2008, at 12:48 AM, Breno de Medeiros wrote:
>>
>>> It is part of the scope of this group to develop a best-practices
>>> guidance for transition from YADIS to XRD discovery.
>>>
>>> Full backward-compatibility is not a goal, since at least one new
>>> mechanism for publishing discovery information is expected to make
>>> part of XRD discovery (dynamic mapping type), and this new mechanism
>>> is being put there (in XRD discovery) in large part because the
>>> current YADIS mechanism makes it difficult for smaller sites to  
>>> become
>>> OPs/RPs by using a hosted solution (so it is an OpenID-driven need  
>>> for
>>> wider adoption).
>>>
>>> XRD discovery is also expected to include a signing mechanism, which
>>> will allow for use of higher-security discovery "profiles".  As part
>>> of this best-practices document, the OpenID discovery spec should  
>>> give
>>> guidance on the security characteristics of each profile. The  
>>> current
>>> mechanism (which limits re-directs and enforces realm authority =
>>> return_to url authority) will constitute a profile and there will
>>> likely be at least a second profile that verifies signatures on the
>>> discovered documents but allow for unmatched realm/return_to URLs.
>>>
>>> That being said, we are certainly aware of the need to make the
>>> transition as smooth as possible, and that is why it is part of the
>>> scope of this group to write a transitions guidance document.
>>>
>>>
>>> On Fri, Dec 19, 2008 at 11:28 PM, Mike Jones
>>> <Michael.Jones at microsoft.com> wrote:
>>>>
>>>> Can you add a clear statement to the draft charter that  
>>>> implementations
>>>> already using Yadis will remain compatible with the output of  
>>>> this working
>>>> group, since, as I understand it, XRDS-Simple is intended to be  
>>>> compatible
>>>> with Yadis?  Or is backwards-compatibility with existing OpenID 2.0
>>>> implementations not a goal of this work?
>>>>
>>>>                             -- Mike
>>>>
>>>> -----Original Message-----
>>>> From: specs-bounces at openid.net [mailto:specs-bounces at openid.net] On
>>>> Behalf Of Breno de Medeiros
>>>> Sent: Thursday, December 18, 2008 6:14 PM
>>>> To: OpenID Specs Mailing List
>>>> Cc: David Recordon; Brian Eaton; Johannes Ernst
>>>> Subject: Proposal to form Working Group
>>>>
>>>> I would like to submit the following proposal for a working group
>>>> charter (also available at
>>>> http://wiki.openid.net/Working_Groups:Discovery):
>>>>
>>>> Services and Metadata Discovery Coordination Working Group  
>>>> (Discovery)
>>>>
>>>> Charter Proposal
>>>>
>>>> In accordance with the OpenID Foundation IPR policies and  
>>>> procedures
>>>> this note proposes the formation of a new working group chartered  
>>>> to
>>>> produce an OpenID specification. As per Section 4.1 of the  
>>>> Policies,
>>>> the proposed charter is below (still liable to change during this
>>>> feedback period).
>>>>
>>>>
>>>> I. Name
>>>>
>>>> Services and Metadata Discovery Coordination Working Group  
>>>> (Discovery)
>>>>
>>>>
>>>> II. Statement of Purpose
>>>>
>>>> Produce a document describing the OpenID discovery workflow,  
>>>> updating
>>>> the current mechanism to describe how to use OASIS specifications  
>>>> for
>>>> discovery, to be drafted by the OASIS XRI TC. The intention is that
>>>> the document will be incorporated as part of some future version of
>>>> the OpenID Authentication spec.
>>>>
>>>>
>>>> III. Scope
>>>>
>>>> Produce a document describing the use of OASIS discovery
>>>> specifications as formulated by the OASIS XRI TC, for normative
>>>> application by all other OpenID specifications. Produce a document
>>>> describing the recommended migration of services discovery from the
>>>> Yadis 1.0 specification to the discovery specifications currently
>>>> being developed by the OASIS XRI TC. All types of identifiers
>>>> addressed by OASIS XRI TC discovery (XRD 1.0) are within scope of  
>>>> this
>>>> WG. Publish a list of service and resource types supported by the
>>>> discovery mechanism.
>>>>
>>>>
>>>> IV. Specifications
>>>>
>>>> OpenID Discovery, including a sub-spec for Trusted OpenID  
>>>> Discovery,
>>>> and a best-practices guidance document for migration.
>>>>
>>>>
>>>> V. Anticipated audience
>>>>
>>>> All those interested in the OpenID specifications.
>>>>
>>>>
>>>> VI. Language of business
>>>>
>>>> English.
>>>>
>>>>
>>>> VII. Method of work
>>>>
>>>> Mailing list discussion. Posting of intermediate drafts in the  
>>>> OpenID
>>>> Wiki. Virtual conferencing on an ad-hoc basis.
>>>>
>>>>
>>>> VIII. Basis for completion of the activity
>>>>
>>>> The discovery document is final and all deliverables have been
>>>> incorporated into the OpenID Authentication spec, perhaps by
>>>> reference.
>>>>
>>>>
>>>> Background Information
>>>>
>>>>
>>>> I. Related Work
>>>>
>>>> XRD 1.0 spec, being drafted by the OASIS XRI TC.
>>>>
>>>>
>>>> II. Initial Membership
>>>>
>>>> * Brian Eaton, beaton at google.com, Google, Inc.
>>>> * Johannes Ernst, jernst at netmesh.us, NetMesh. (editor)
>>>> * Eran Hammer-Lahav, eran at hueniverse.com, Yahoo! Inc.
>>>> * Breno de Medeiros, breno at google.com, Google, Inc. (editor)
>>>> * David Recordon, david at sixapart.com, Six Apart Ltd.
>>>> * Drummond Reed, drummond.reed at cordance.net, Cordance
>>>> * Nat Sakimura, n-sakimura at nri.co.jp, NRI
>>>>
>>>> --
>>>> --Breno
>>>>
>>>> +1 (650) 214-1007 desk
>>>> +1 (408) 212-0135 (Grand Central)
>>>> MTV-41-3 : 383-A
>>>> PST (GMT-8) / PDT(GMT-7)
>>>> _______________________________________________
>>>> specs mailing list
>>>> specs at openid.net
>>>> http://openid.net/mailman/listinfo/specs
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> --Breno
>>>
>>> +1 (650) 214-1007 desk
>>> +1 (408) 212-0135 (Grand Central)
>>> MTV-41-3 : 383-A
>>> PST (GMT-8) / PDT(GMT-7)
>>
>>
>>
>
>
>
> -- 
> --Breno
>
> +1 (650) 214-1007 desk
> +1 (408) 212-0135 (Grand Central)
> MTV-41-3 : 383-A
> PST (GMT-8) / PDT(GMT-7)
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2557 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20081222/82c27a9b/attachment-0002.bin>


More information about the specs mailing list