Re: Modularizing Auth 2.0 Discovery

2007-02-28 Thread Mark Baker
On 2/28/07, Martin Atkins [EMAIL PROTECTED] wrote:
 My proposal is that we make the core Auth 2.0 spec scheme-agnostic.

+1

Mark.
-- 
Mark Baker.  Ottawa, Ontario, CANADA. http://www.markbaker.ca
Coactus; Web-inspired integration strategies  http://www.coactus.com
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs


Re: Modularizing Auth 2.0 Discovery

2007-02-28 Thread Martin Atkins
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

2007-02-28 Thread Recordon, David
+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

2007-02-28 Thread Rowan Kerr
Sounds interesting.. +1 :)
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs


Re: Modularizing Auth 2.0 Discovery

2007-02-28 Thread rob
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

2007-02-28 Thread Drummond Reed
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

2007-02-28 Thread Recordon, David
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

2007-02-28 Thread Martin Atkins
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

2007-02-28 Thread Drummond Reed

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.

If OpenID Discovery is a single, separate, referencable spec, then it
doesn't even have to do that. OpenID Authentication 2.0 can just say
something like:

OpenID is an open, extensible framework for associated identity services
with an identifier. Discovery of the metadata necessary for an OpenID
consuming application to access those services is specified by the OpenID
Discovery specification [reference here].

+1

Rob wrote:
can we also use the opportunity to put i-names support in an extension?

Under this approach, discovery all identifiers (URLs, XRI i-names/i-numbers,
email addresses, phone numbers, etc.) would be handled by OpenID Discovery.

=Drummond 

___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs


Re: Modularizing Auth 2.0 Discovery

2007-02-28 Thread Martin Atkins
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

2007-02-28 Thread Martin Atkins
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

2007-02-28 Thread Recordon, David
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

2007-02-28 Thread Martin Atkins
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

2007-02-28 Thread Recordon, David
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

2007-02-28 Thread Martin Atkins
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


RE: Modularizing Auth 2.0 Discovery

2007-02-28 Thread Recordon, David
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

2007-02-28 Thread Rowan Kerr
On 2/28/07, Martin Atkins [EMAIL PROTECTED] wrote:
 I like the idea of ditching the reference to Yadis spec and moving the
 parts about finding the XRDS document into my hypothetical OpenID
 Discovery for HTTP/HTTPS URLs specification and the parts about
 processing the XRDS document into the OpenID Auth spec.

Aren't XRDS documents useful for more than just HTTP discovery?
I mean, I'd expect that the document you'd discover via any method
would always be an XRDS...

-Rowan
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs


RE: Modularizing Auth 2.0 Discovery

2007-02-28 Thread Drummond Reed

Martin Atkins wrote:

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?

The XRI Technical Committee has been working with the OpenID community for
the last year to make sure the XRI Resolution spec is cleanly modular so
that independent pieces of it can be referenced as needed by other specs.
Yadis already does that. Given the extra overhead each spec carries at a SDO
like OASIS, it would be much easier for OpenID Discovery to reference just
the parts of XRI Resolution that it needs. 

But I suggest we close on the best approach for OpenID Discovery first. I'll
answer a different question you posed about that next.

=Drummond 

___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs


Re: Modularizing Auth 2.0 Discovery

2007-02-28 Thread rob
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

2007-02-28 Thread Alaric Dailey
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

2007-02-28 Thread Drummond Reed

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

2007-02-28 Thread Gabe Wachob

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

2007-02-28 Thread Dmitry Shechtman
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

2007-02-28 Thread Recordon, David
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

2007-02-28 Thread Martin Atkins

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

2007-02-28 Thread Martin Atkins
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

2007-02-28 Thread Martin Atkins
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

2007-02-28 Thread Alaric Dailey
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


RE: HTTPS status

2007-02-28 Thread Alaric Dailey
I was going to sit here and craft a large response with rebuttals for each
of your statements, but... 

At this point I think I have to be contented with the knowledge that OpenId
will be forced to change, or it will fail, this is ESPECIALLY true because
of the sudden surge in popularity.
  

 -Original Message-
 From: [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED] On Behalf Of Scott Kveton
 Sent: Wednesday, February 28, 2007 8:33 PM
 To: specs@openid.net
 Subject: Re: HTTPS status
 
 [snip]
  
  Why is there such reluctance?
 
 I think there are a several reasons why:
 
 * Not everybody knows how to install/manage an SSL certificate
 * Not every web hosting company allows multiple IP's for sites
 * It wouldn't have been easy to get the adoption we're seeing 
 with a MUST
 * Majority of transactions are low-value today
 
 Could we have gotten where we are today with the growth that 
 we've seen _with_ a MUST?  I don't think so.
 
 The providers who are really serious about security and 
 identity will have SSL.
 
 - Scott
 
 ___
 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: HTTPS status

2007-02-28 Thread Scott Kveton
 At this point I think I have to be contented with the knowledge that OpenId
 will be forced to change, or it will fail, this is ESPECIALLY true because
 of the sudden surge in popularity.

Absolutely ... I didn't put won't ever in any of those bullet points.
OpenID is always going to change, evolve and mature.  It has to.  It has
already in the last 18 months and will continue to do so.  If it doesn't,
that's when we really have to worry about failure.

- Scott







 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] On Behalf Of Scott Kveton
 Sent: Wednesday, February 28, 2007 8:33 PM
 To: specs@openid.net
 Subject: Re: HTTPS status
 
 [snip]
 
 Why is there such reluctance?
 
 I think there are a several reasons why:
 
 * Not everybody knows how to install/manage an SSL certificate
 * Not every web hosting company allows multiple IP's for sites
 * It wouldn't have been easy to get the adoption we're seeing
 with a MUST
 * Majority of transactions are low-value today
 
 Could we have gotten where we are today with the growth that
 we've seen _with_ a MUST?  I don't think so.
 
 The providers who are really serious about security and
 identity will have SSL.
 
 - Scott
 
 ___
 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]

2007-02-28 Thread David Fuelling
 -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


Re: Multiple values for one key in requests/responses

2007-02-28 Thread Tomi Pieviläinen
On Mon, Feb 26, 2007 at 12:19:49AM -0800, Dick Hardt wrote:
 Conscience design decision to not allow multiple values per key as  
 some languages (PHP) it is hard to differentiate them.
 
 Solution is either have different keys for each value, or define  
 delimiter so that you can have multiple values contained in the one  
 value string for a given key.

Seems like this hasn't roused any feelings, but I still think that
there should be a way. I don't see how different keys could work but a
delimiter would be fine. There needs to be a reasonable way to
negotiate common capabilities between the RP and OP.

-- 
Tomi Pieviläinen, +358 400 487 504
I will sit down now, but the time will come when you will hear me.
- Benjamin Disraeli, 1st Earl of Beaconsfield


signature.asc
Description: Digital signature
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs