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 <br...@google.com> Subject: Re: Proposal to form Discovery Working Group To: da...@sixapart.com Cc: Brian Eaton <bea...@google.com>, OpenID Specs Mailing List <specs@openid.net>, Johannes Ernst <jer...@netmesh.us> Message-ID: <29fb00360812221107g5cd69346gfcac57575601f...@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 <drecor...@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 dateversus 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 thecurrent YADIS mechanism makes it difficult for smaller sites to become OPs/RPs by using a hosted solution (so it is an OpenID-driven need forwider adoption). XRD discovery is also expected to include a signing mechanism, which will allow for use of higher-security discovery "profiles". As partof this best-practices document, the OpenID discovery spec should give guidance on the security characteristics of each profile. The currentmechanism (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.jo...@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 compatiblewith Yadis? Or is backwards-compatibility with existing OpenID 2.0 implementations not a goal of this work? -- Mike -----Original Message----- From: specs-boun...@openid.net [mailto:specs-boun...@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 ProposalIn 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. NameServices and Metadata Discovery Coordination Working Group (Discovery)II. Statement of PurposeProduce a document describing the OpenID discovery workflow, updating the current mechanism to describe how to use OASIS specifications fordiscovery, 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 identifiersaddressed by OASIS XRI TC discovery (XRD 1.0) are within scope of thisWG. Publish a list of service and resource types supported by the discovery mechanism. IV. SpecificationsOpenID 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 workMailing list discussion. Posting of intermediate drafts in the OpenIDWiki. 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, bea...@google.com, Google, Inc. * Johannes Ernst, jer...@netmesh.us, NetMesh. (editor) * Eran Hammer-Lahav, e...@hueniverse.com, Yahoo! Inc. * Breno de Medeiros, br...@google.com, Google, Inc. (editor) * David Recordon, da...@sixapart.com, Six Apart Ltd. * Drummond Reed, drummond.r...@cordance.net, Cordance * Nat Sakimura, n-sakim...@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@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)
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
