Re: Modularizing Auth 2.0 Discovery
Dmitry Shechtman wrote: Then we'd publish in parallel the following two ancillary specifications: * OpenID Discovery for HTTP and HTTPS URIs * OpenID Discovery for XRI URIs. The latter being prepend http://xri.net/ to the XRI and use OpenID Discovery for HTTP. I think as a starting point we should just refactor the existing XRI-related content from the Auth spec into a separate spec. We can then worry about simplifying it as a separate problem. Later, the OpenID community or a third party could publish a specification OpenID Discovery for Email Addresses, but I don't think we're really ready to go there right now. Could you please elaborate on this? I believe the SMTP Extension is pretty solid. The only thing it lacks is formality. I'd rather not get into the debate about email-based identifiers here. This thread is about making it possible to have such a spec, not about which spec will be adopted and when. I encourage you to pursue this separately, assuming we actually do modularize the auth spec. Cheers, Martin ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Modularizing Auth 2.0 Discovery
+1, I'm fully in support of this and actually have been wanting to do so for quite a number of weeks now! --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Martin Atkins Sent: Wednesday, February 28, 2007 10:44 AM To: specs@openid.net Subject: Modularizing Auth 2.0 Discovery Recently there has been talk about using alternative identifiers for OpenID, such as email addresses and Jabber Identifiers. This has made it obvious that the OpenID Authentication protocol doesn't care in the slightest what the identifier is as long as service discovery can be performed on it somehow. Currently the Authentication 2.0 specification has language in various places that constrains it to URIs with the schemes http, https and xri. For example, under Terminology the following definition is given for Identifier: An Identifier is either a http or https URI, (commonly referred to as a URL within this document), or an XRI [XRI_Syntax_2.0]. This document defines various kinds of Identifiers, designed for use in different contexts. My proposal is that we make the core Auth 2.0 spec scheme-agnostic. It would just state that an identifier is a URI. Later in the spec, where currently it enumerates a bunch of ways to do discovery, it'd just say do discovery on the URI using an appropriate protocol. (or, indeed, words to that effect.) It would also nominate a standard XRDS service type URI to use during Yadis discovery. Then we'd publish in parallel the following two ancillary specifications: * OpenID Discovery for HTTP and HTTPS URIs * OpenID Discovery for XRI URIs. Later, the OpenID community or a third party could publish a specification OpenID Discovery for Email Addresses, but I don't think we're really ready to go there right now. The discovery protocols don't necessarily need to be XRDS-based, but if they are they would presumably reference the standard service type URI from the Auth spec so that future Auth versions can change this without needing to re-publish the discovery specs. This has the following benefits: * It gives others a clear, spec-approved mechanism to bolt-on support for additional URI schemes. * It allows the Authentication specification to evolve separately from the various discovery specifications, which are unlikely to need to change very much from version-to-version. * It formalizes the separation between discovery and authentication, giving library authors a clear plug-in point if they wish to support modular discovery. Presumably the OpenID Auth 2.0 spec would still retain a reference to the HTTP and HTTPS discovery spec purely so that it can say that RPs MUST support it regardless of what else they support. - All ancillary discovery specifications must, at minimum, define: * A pattern for recognizing and canonicalizing their own identifiers. (For example, the XRI one would include a provision for checking for an identifier which starts with a global context symbol, etc.) * A mechanism for returning the following information: - Either: (traditional identity case) * Canonical Claimed identifier (an i-number, for example) * User-supplied Display identifier (an i-name, for example) * OP endpoint URL * OP-local identifier (i.e. openid:Delegate as was) - Or: (directed identity case) * OP endpoint URL * Canonical OP identifier (for use in confirmation messages) (And, of course, not all discovery mechanisms would necessarily support directed identity.) ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Modularizing Auth 2.0 Discovery
Martin Atkins wrote: My proposal is that we make the core Auth 2.0 spec scheme-agnostic. It would just state that an identifier is a URI. Later in the spec, where currently it enumerates a bunch of ways to do discovery, it'd just say do discovery on the URI using an appropriate protocol. (or, indeed, words to that effect.) It would also nominate a standard XRDS service type URI to use during Yadis discovery. +1 can we also use the opportunity to put i-names support in an extension? ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Modularizing Auth 2.0 Discovery
I've always been supportive of breaking out OpenID Discovery into a separate spec. I wouldn't break it out into separate specs, however, because discovery for any OpenID identifier has have much more in common than they have different. For example, they all need to explain the relationship of the identifier being resolve to an XRDS document and the metadata needed to access other OpenID services. So I'm make the OpenID Discovery spec modular rather than breaking it out into separate specs. It also very nicely fits the OpenID layer model, i.e., one specification (one might argue the foundational spec) for OpenID Discovery -- the layer that maps an OpenID identifier to the metadata needed to access an OpenID service -- followed by a specification for OpenID Authentication, and then other specs from there. In fact, I'm excited enough about this approach that I'll volunteer to be one of the editors for OpenID Discovery. I can specifically handle coordination between the OpenID Discovery spec and the XRDS definitions in the XRI Resolution spec at OASIS. =Drummond -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Recordon, David Sent: Wednesday, February 28, 2007 11:26 AM To: Martin Atkins; specs@openid.net Subject: RE: Modularizing Auth 2.0 Discovery +1, I'm fully in support of this and actually have been wanting to do so for quite a number of weeks now! --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Martin Atkins Sent: Wednesday, February 28, 2007 10:44 AM To: specs@openid.net Subject: Modularizing Auth 2.0 Discovery Recently there has been talk about using alternative identifiers for OpenID, such as email addresses and Jabber Identifiers. This has made it obvious that the OpenID Authentication protocol doesn't care in the slightest what the identifier is as long as service discovery can be performed on it somehow. Currently the Authentication 2.0 specification has language in various places that constrains it to URIs with the schemes http, https and xri. For example, under Terminology the following definition is given for Identifier: An Identifier is either a http or https URI, (commonly referred to as a URL within this document), or an XRI [XRI_Syntax_2.0]. This document defines various kinds of Identifiers, designed for use in different contexts. My proposal is that we make the core Auth 2.0 spec scheme-agnostic. It would just state that an identifier is a URI. Later in the spec, where currently it enumerates a bunch of ways to do discovery, it'd just say do discovery on the URI using an appropriate protocol. (or, indeed, words to that effect.) It would also nominate a standard XRDS service type URI to use during Yadis discovery. Then we'd publish in parallel the following two ancillary specifications: * OpenID Discovery for HTTP and HTTPS URIs * OpenID Discovery for XRI URIs. Later, the OpenID community or a third party could publish a specification OpenID Discovery for Email Addresses, but I don't think we're really ready to go there right now. The discovery protocols don't necessarily need to be XRDS-based, but if they are they would presumably reference the standard service type URI from the Auth spec so that future Auth versions can change this without needing to re-publish the discovery specs. This has the following benefits: * It gives others a clear, spec-approved mechanism to bolt-on support for additional URI schemes. * It allows the Authentication specification to evolve separately from the various discovery specifications, which are unlikely to need to change very much from version-to-version. * It formalizes the separation between discovery and authentication, giving library authors a clear plug-in point if they wish to support modular discovery. Presumably the OpenID Auth 2.0 spec would still retain a reference to the HTTP and HTTPS discovery spec purely so that it can say that RPs MUST support it regardless of what else they support. - All ancillary discovery specifications must, at minimum, define: * A pattern for recognizing and canonicalizing their own identifiers. (For example, the XRI one would include a provision for checking for an identifier which starts with a global context symbol, etc.) * A mechanism for returning the following information: - Either: (traditional identity case) * Canonical Claimed identifier (an i-number, for example) * User-supplied Display identifier (an i-name, for example) * OP endpoint URL * OP-local identifier (i.e. openid:Delegate as was) - Or: (directed identity case) * OP endpoint URL * Canonical OP identifier (for use in confirmation messages) (And, of course, not all discovery mechanisms would necessarily support directed identity.) ___ specs
RE: Modularizing Auth 2.0 Discovery
Well there already is the Yadis spec. Maybe the Yadis spec remains separate versus becoming part of the OASIS XRI Resolution document? --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Martin Atkins Sent: Wednesday, February 28, 2007 11:59 AM To: specs@openid.net Subject: Re: Modularizing Auth 2.0 Discovery Martin Atkins wrote: My proposal is that we make the core Auth 2.0 spec scheme-agnostic. Attached is a version of the current spec draft 11 with large chunks of the discovery/normalization stuff hacked out and replaced with generic see other specifications text. I think I may have deleted too much in that we've lost the detailed rules for dealing with XRDS documents, which are probably going to be referenced by most discovery specs and deserve to be in the core spec. See the TODO: markers for more info. However, in doing this it also occured to me that it would be very useful to have the XRDS-related bits of the XRI resolution spec in a separate document that we could reference, since our new protocol-agnostic core Auth 2.0 spec has no need for the rest of XRI resolution. I wonder if the XRI guys would consider making Chapter 3 of the XRI Resolution 2.0 spec into a separate document that OpenID Auth could reference directly? ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Modularizing Auth 2.0 Discovery
rob wrote: Martin Atkins wrote: My proposal is that we make the core Auth 2.0 spec scheme-agnostic. It would just state that an identifier is a URI. Later in the spec, where currently it enumerates a bunch of ways to do discovery, it'd just say do discovery on the URI using an appropriate protocol. (or, indeed, words to that effect.) It would also nominate a standard XRDS service type URI to use during Yadis discovery. +1 can we also use the opportunity to put i-names support in an extension? If this were to take the form I described in my original message, effectively *all* discovery mechanisms become extensions. The HTTP/HTTPS one gets special treatment by getting referenced by a MUST in the core spec, but it's still a separate document. i-names would be handled as part of the OpenID Discovery for XRI URIs specification I mentioned. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Modularizing Auth 2.0 Discovery
Drummond Reed wrote: I've always been supportive of breaking out OpenID Discovery into a separate spec. I wouldn't break it out into separate specs, however, because discovery for any OpenID identifier has have much more in common than they have different. For example, they all need to explain the relationship of the identifier being resolve to an XRDS document and the metadata needed to access other OpenID services. My revised proposal is that the Authentication specification would include, as part of a Requirements for Discovery Protocols section, a section on the use of an XRDS document as part of discovery. The separate discovery specs would then describe identifier recognition and canonicalization, how to retrieve an XRDS document and any other special non-XRDS mechanisms as appropriate. So the HTTP/HTTPS one, for example, would: * Describe How to recognise and canonicalize its identifiers * Require the use of Yadis discovery to obtain the XRDS document * Refer to the relevant section of OpenID Authentication for the XRDS processing rules. * Require that if Yadis fails RPs fall back on the non-XRDS-based HTML discovery, describing how this mode returns the necessary information. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Modularizing Auth 2.0 Discovery
Recordon, David wrote: Well there already is the Yadis spec. Maybe the Yadis spec remains separate versus becoming part of the OASIS XRI Resolution document? The XRDS-related parts of the Yadis specification seem to duplicate requirements from XRI Resolution chapter 3. In the interests of avoiding redundancy, I'd suggest the following distinction: 1. XRI Resolution chapter 3 (or a separate spin-off spec) describes the syntax of an XRDS document. 2. Yadis describes how to obtain an XRDS document for an HTTP or HTTPS URL. 3. OpenID Authentication describes how to determine the endpoint URI and other information from an XRDS document, referencing [1]. 4. The new HTTP discovery specification would reference [2] and [3] to describe the XRDS-based HTTP discovery mode, and then go on to describe the HTML-based discovery fallback. Alternatively, [3] above could be served by a separate spec OpenID discovery using XRDS, though I think that may be overkill for something so straightforward. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Modularizing Auth 2.0 Discovery
Works for me, one thing though is the Yadis spec specifically highlights the bits of the XRDS file which are relevant in this sort of use case. If chapter 3 is separate then this would be a smaller concern for me, but I think part of the *ugh* feeling people get is having to read about the full XRDS schema. --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Martin Atkins Sent: Wednesday, February 28, 2007 12:17 PM Cc: specs@openid.net Subject: Re: Modularizing Auth 2.0 Discovery Recordon, David wrote: Well there already is the Yadis spec. Maybe the Yadis spec remains separate versus becoming part of the OASIS XRI Resolution document? The XRDS-related parts of the Yadis specification seem to duplicate requirements from XRI Resolution chapter 3. In the interests of avoiding redundancy, I'd suggest the following distinction: 1. XRI Resolution chapter 3 (or a separate spin-off spec) describes the syntax of an XRDS document. 2. Yadis describes how to obtain an XRDS document for an HTTP or HTTPS URL. 3. OpenID Authentication describes how to determine the endpoint URI and other information from an XRDS document, referencing [1]. 4. The new HTTP discovery specification would reference [2] and [3] to describe the XRDS-based HTTP discovery mode, and then go on to describe the HTML-based discovery fallback. Alternatively, [3] above could be served by a separate spec OpenID discovery using XRDS, though I think that may be overkill for something so straightforward. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Modularizing Auth 2.0 Discovery
Drummond Reed wrote: Under this approach, discovery all identifiers (URLs, XRI i-names/i-numbers, email addresses, phone numbers, etc.) would be handled by OpenID Discovery. I disagree that a single spec can contain discovery rules for all conceivable discovery types without becoming ridiculously big. The discovery rules in the current spec for just handling HTTP/HTTPS and XRI discovery are already big enough. However, I clearly have a bias for lots of small specs over one large spec, and clearly your bias is the opposite. :) ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Modularizing Auth 2.0 Discovery
I'd be happy with either approach. One spec with a section on each type or separate specs for each. I think small separate specs are slightly harder to comprehend, though make it easer for things like the SMTP extension to develop. --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Martin Atkins Sent: Wednesday, February 28, 2007 12:24 PM Cc: specs@openid.net Subject: Re: Modularizing Auth 2.0 Discovery Drummond Reed wrote: Under this approach, discovery all identifiers (URLs, XRI i-names/i-numbers, email addresses, phone numbers, etc.) would be handled by OpenID Discovery. I disagree that a single spec can contain discovery rules for all conceivable discovery types without becoming ridiculously big. The discovery rules in the current spec for just handling HTTP/HTTPS and XRI discovery are already big enough. However, I clearly have a bias for lots of small specs over one large spec, and clearly your bias is the opposite. :) ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Modularizing Auth 2.0 Discovery
Yeah, I'd see this either as a Yadis 1.1 (using things like LocalID versus OpenID:Delegate) or have the OpenID URL Discovery spec replace Yadis, referencing chapter 3 as needed. I think I'd lean toward swallowing Yadis in as a part of this spec so it is one fewer documents people need to read in total. --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Martin Atkins Sent: Wednesday, February 28, 2007 12:27 PM To: specs@openid.net Subject: Re: Modularizing Auth 2.0 Discovery Recordon, David wrote: Works for me, one thing though is the Yadis spec specifically highlights the bits of the XRDS file which are relevant in this sort of use case. If chapter 3 is separate then this would be a smaller concern for me, but I think part of the *ugh* feeling people get is having to read about the full XRDS schema. Perhaps then Yadis (or something else) can describe the subset of the XRDS schema used for service discovery, referencing the full XRDS specification only as a formality? I agree that XRI Resolution chapter 3 is a bit big for our purposes. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Modularizing Auth 2.0 Discovery
Recordon, David wrote: I think I'd lean toward swallowing Yadis in as a part of this spec so it is one fewer documents people need to read in total. +1 does this open up the potential to change Yadis? I certainly found the spec confusing on a few points when I first read it i.e. 1) Two xml namespaces, why? 2) Confusing namespace names, xri://$xrd*($v*2.0) this is just plain confusing for someone not familiar with i-names. 3) Then finally this text If a Yadis XRDS includes more than one XRD element, the Yadis Resource Descriptor is the last XRD element. A Relying Party Agent MAY ignore other XRD elements. Again, just confused me, couldn't see the point of the seemingly redundant xrd element or understand when there would be more than one. / /Rob ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
HTTPS status
Eddy Nigg and I brought up the issue of requiring SSL a while back, since then I have been swamped, it looked like there was some more talk about it since then. I know that there are several other people, that are concerned about this too, and it has even been blogged about ( http://www.tbray.org/ongoing/When/200x/2007/02/24/OpenID ) Can someone please tell me the status on this? Hopefully its being required! ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Modularizing Auth 2.0 Discovery
Drummond Reed wrote: Under this approach, discovery all identifiers (URLs, XRI i-names/i-numbers, email addresses, phone numbers, etc.) would be handled by OpenID Discovery. Martin Atkins wrote: I disagree that a single spec can contain discovery rules for all conceivable discovery types without becoming ridiculously big. The discovery rules in the current spec for just handling HTTP/HTTPS and XRI discovery are already big enough. I'm not proposing a single spec for all discovery rules for all types of identifiers forever. I am proposing a spec that: 1) Sets out the general framework and requirements for OpenID Discovery because there is a lot that discovery for any identifier will have in common (for example, the general rules around XRDS usage). 2) Include sections for the specific identifier types that are already well-known and implemented -- URLs and XRIs. 3) Specifies how it extensions can be written for other identifiers, such as email addresses, phone numbers, SIP endpoints, etc. However, I clearly have a bias for lots of small specs over one large spec, and clearly your bias is the opposite. :) Why do you say that? I've been doing specs for a decade now both inside and outside of SDOs, and I don't think anyone I've ever worked with would say, Drummond likes great big bulky specifications. In fact, they would tell you I absolutely hate them. David and I did a joint paper/presentation on OpenID at the last's fall ACM conference and we specifically touted OpenID's modular lightweight specification approach. But more than anything I'm a big believe Einstein's as simple as possible but no simpler. In this case, I believe the OpenID framework should have a clear, cohesive discovery layer, and to do that, it should be anchored in an OpenID Discovery spec. =Drummond ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Proposal for Modularizing Auth 2.0 Discovery
I'm trying to follow this while at ETEL - not all of us can keep up with
this list on a minute-by-minute basis ;-)
Here's a proposal for a modular OpenID Discovery Spec, which I'll volunteer
to help edit since I am responsible for the XRI resolution spec and the XRDS
document format.
Basically, the Discovery Spec would specify that for any identifier scheme
to work with OpenID, it MUST define a way of being constructed into an HTTP
URI and then returning a XRDS with an HTTP GET on that HTTP URI. If there
are other ways of resolving it, then implementations MAY use those other
methods of resolution (native resolution, if you will). In essence, this
is a requirement for HTTP gateway(s) to whatever resolution infrastructure
exists today.
This is exactly what we do with XRIs -- http://xri{.domain*}/xri?some
stuff is the form of the HTTP URL and it gets back the XRDS you need.
Implementations can also do native XRI resolution (which is a series of HTTP
requests) - but they are not required to (there will be advantages to doing
this in the future, but implementations won't be required to do native
resolution).
Of course, it's pretty much a null-op for HTTP URIs, except that there's a
fallback for doing HTML-based discovery.
---
I'd also support some way of making the specs for XRDS easier to comprehend
for non-XRI developers. In particular, a profile for XRDS which says which
elements are important for the common functions of OpenID.
-Gabe
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs
RE: Proposal for Modularizing Auth 2.0 Discovery
I'd agree on specifying HTTP as the only resolution method required. Unfortunately, I have a conflict of interests with the SMTP service extension... Regards, Dmitry =damnian ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Modularizing Auth 2.0 Discovery
I'd like to stay away from changing it much, but I do agree there are some warts which have been found. Also by taking advantage of things in the XRDS schema which exist now such as the LocalID element we'd be able to remove the OpenID XMLNS for example. --David -Original Message- From: rob [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 28, 2007 1:03 PM To: Recordon, David Cc: Martin Atkins; specs@openid.net Subject: Re: Modularizing Auth 2.0 Discovery Recordon, David wrote: I think I'd lean toward swallowing Yadis in as a part of this spec so it is one fewer documents people need to read in total. +1 does this open up the potential to change Yadis? I certainly found the spec confusing on a few points when I first read it i.e. 1) Two xml namespaces, why? 2) Confusing namespace names, xri://$xrd*($v*2.0) this is just plain confusing for someone not familiar with i-names. 3) Then finally this text If a Yadis XRDS includes more than one XRD element, the Yadis Resource Descriptor is the last XRD element. A Relying Party Agent MAY ignore other XRD elements. Again, just confused me, couldn't see the point of the seemingly redundant xrd element or understand when there would be more than one. / /Rob ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Modularizing Auth 2.0 Discovery
Having reflected on people's comments a bit, I have a slightly adjusted set of proposals. 1. Take the bits about parsing XRD service elements from the Yadis spec and call it XRD service discovery for URIs. 2. Have XRD service discovery delegate the actual mapping of a URI onto an XRD element to ancillary specs as before. These will define recognition/normalization rules for user input and how to take a matching URI and return an appropriate XRD element. 3. Create XRD discovery for HTTP URLs which is really just the remaining stuff out of Yadis. * * HTML-based Discovery for OpenID remains a special case, but we can minimize the reach of this special case by stating in the HTTP URLs spec that if HTML-based discovery succeeds an implementation is to synthesize (or at least, act as if it synthesized) a functionally-equivalent XRD element containing Service elements for OpenID 1 and/or OpenID 2. 4. Have OpenID Authentication 2 simply say “use XRD service discovery to find a service description for ‘http://specs.openid.net/auth/2.0/server’ or ‘http://specs.openid.net/auth/2.0/signon’” and then…” and go on to describe the interpretation of the URI element and the LocalID element. It'd also contain a special provision that RPs MUST support HTTP-based discovery, to retain the baseline functionality from OpenID 1.1. The minimal reading for an OpenID Auth RP implementor then becomes: * Core OpenID spec * XRD service discovery * XRD discovery for HTTP URLs While the idea of having three required specs is a little scary, these three should be able to stand alone and the latter two will be quite simple since they are just formed by splitting Yadis in half. XRD discovery for XRIs barely needs defining since XRI resolution already covers most of it. Just need to bring over the recognition/normalization rules from the Auth Draft 11 section 7.2. - This also maps nicely onto a potential set of libraries: * 1 glue library that takes as input a URI and a list of service types in order of preference and returns an XRDS Service element representing the best match. findService(URI, serviceTypes[]) * n discovery libraries which have three operations: isMyIdentifier(string) - determine if this library owns this identifier. normalizeIdentifier(string) - return a normalized version of the identifier. findXRD(URI) - retrieve an XRD element for the given URI. These are called by the glue library and then the glue library parses the returned XRD element. * 1 OpenID library which does: service = discovery.findService(=mart, [ http://specs.openid.net/auth/2.0/server;, http://specs.openid.net/auth/2.0/signon;, ]) endpoint = service.getURI() localid = service.getLocalID() || =mart // etc, etc ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Proposal for Modularizing Auth 2.0 Discovery
Gabe Wachob wrote: Basically, the Discovery Spec would specify that for any identifier scheme to work with OpenID, it MUST define a way of being constructed into an HTTP URI and then returning a XRDS with an HTTP GET on that HTTP URI. If there are other ways of resolving it, then implementations MAY use those other methods of resolution (native resolution, if you will). In essence, this is a requirement for HTTP gateway(s) to whatever resolution infrastructure exists today. I don't really think it's necessary to *mandate* that a HTTP mapping always be used. After all, it's very easy for a spec to, if it's appropriate, define a mapping to an HTTP URL and then reference the HTTP-based discovery spec. While I agree that at this point any discovery protocol that *doesn't* use HTTP is going to face an uphill struggle as far as real-world implementations go, if people want to go ahead and try to get their off-the-wall protocols adopted I don't see any reason why we shouldn't let them. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: HTTPS status
Alaric Dailey wrote: Eddy Nigg and I brought up the issue of requiring SSL a while back, since then I have been swamped, it looked like there was some more talk about it since then. I know that there are several other people, that are concerned about this too, and it has even been blogged about ( http://www.tbray.org/ongoing/When/200x/2007/02/24/OpenID ) Can someone please tell me the status on this? Hopefully its being required! As far as I'm aware, the current status is: * All OpenID identifiers SHOULD use a secure channel. * All OpenID servers SHOULD use a secure channel. * OpenID relying parties MUST support SSL access to HTTP URLs. * OpenID relying parties MAY refuse to interface with identifiers and servers that do not use a secure channel. * All other connections are out of scope of OpenID Authentication. I may be wrong on these, as I'm listing them from memory. In practice, I expect all big OpenID providers will support SSL because users will demand it. The sites currently providing OpenID identifiers as value-add features alongside an existing service (LiveJournal, etc.) probably won't get used much once there are more proper providers. People hosting their own identifiers and/or OPs probably won't use SSL, but then they won't be able to use their identifiers at any site which requires SSL-based OpenID Authentication, and they'll be in the minority anyway. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: HTTPS status
That wording is better than I remember, but really with free certificates being readily available, and the obvious need for prtecting users data, WHY oh WHY is there even support for an unencrypted channel? Heck even Jabber is being moved to a completely secure end to end encrypted channel. With this being created brand new, why start insecure? I realize I am repeating the same thing I started a few months ago, but with MS and AOL supporting OpenID, it means a lot more users will be exposed to it, making it even more important to do it right from the beginning. Why is there such reluctance? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Martin Atkins Sent: Wednesday, February 28, 2007 6:14 PM To: specs@openid.net Subject: Re: HTTPS status Alaric Dailey wrote: Eddy Nigg and I brought up the issue of requiring SSL a while back, since then I have been swamped, it looked like there was some more talk about it since then. I know that there are several other people, that are concerned about this too, and it has even been blogged about ( http://www.tbray.org/ongoing/When/200x/2007/02/24/OpenID ) Can someone please tell me the status on this? Hopefully its being required! As far as I'm aware, the current status is: * All OpenID identifiers SHOULD use a secure channel. * All OpenID servers SHOULD use a secure channel. * OpenID relying parties MUST support SSL access to HTTP URLs. * OpenID relying parties MAY refuse to interface with identifiers and servers that do not use a secure channel. * All other connections are out of scope of OpenID Authentication. I may be wrong on these, as I'm listing them from memory. In practice, I expect all big OpenID providers will support SSL because users will demand it. The sites currently providing OpenID identifiers as value-add features alongside an existing service (LiveJournal, etc.) probably won't get used much once there are more proper providers. People hosting their own identifiers and/or OPs probably won't use SSL, but then they won't be able to use their identifiers at any site which requires SSL-based OpenID Authentication, and they'll be in the minority anyway. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
What Should an OpenId Be? [WAS: RE: Proposal for Modularizing Auth 2.0 Discovery]
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gabe Wachob Sent: Wednesday, February 28, 2007 3:02 PM To: 'Drummond Reed'; 'Martin Atkins'; specs@openid.net Subject: Proposal for Modularizing Auth 2.0 Discovery snip Basically, the Discovery Spec would specify that for any identifier scheme to work with OpenID, it MUST define a way of being constructed into an HTTP URI and then returning a XRDS with an HTTP GET on that HTTP URI. If there are other ways of resolving it, then implementations MAY use those other methods of resolution (native resolution, if you will). In essence, this is a requirement for HTTP gateway(s) to whatever resolution infrastructure exists today. +1. Wherever we go from here, we need to be clear and define exactly what *is* and what *is not* an Open Id Identifier. A while back there was understatementsome talk/understatement about whether email addresses should be used as 1st-Class or 2nd-Class OpenIds (see the wiki here http://openid.net/wiki/index.php/Debating_Emails_as_1st-Class_or_2nd-Class_C itizens). I think it is important to be clear that it is *not* a great idea to use certain other identifiers (email address, phone number, etc) *as* OpenIds. Rather, these should instead map to OpenId Http URL's (or XRI's if possible). This is important because profile attributes like email address, telephone number, etc may or may not be private in certain circumstances. For example, logging-in with my email address at an RP, which maps my email address to a publicly-displayable OpenId, is an ok thing to do assuming I trust the RP with my email address (The RP will hopefully respect my privacy by displaying my mapped OpenId URL or XRI on publicly facing pages where appropriate). If we drift into the territory that says emails addresses (or other profile attributes) *are* OpenIds, then RP's and end-users will run into lots of problems -- E.g., an RP has a publicly facing page that needs to show a user's identifier, but doing so with an email OpenId would be bad for the end user, so the RP is stuck. Bottom Line (repeating myself): We need to be clear and define exactly what *is* and what *is not* an Open Id Identifier. I think the current spec is right on the money here: OpenId Identifiers should be an Http URI or an XRI. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
