Re: DRAFT 11 -> FINAL?

[Josh Hoyt]

On 1/30/07, Recordon, David <[EMAIL PROTECTED]> wrote:
> Yeah, I'm not a big fan of openid2.* though it was the simplest method
> of fixing up HTML discovery to work with multiple protocol versions.  I
> know Josh thought about this more than I did though.

1. Before authentication is initiated, the RP needs to determine what
the protocol is. This could be done via discovery on the OP, but there
has been general rejection of adding yet another discovery step.

2. A user may have one service that provides OpenID 1 and another that
provides OpenID 2. If this is the case, then the version information
needs to be bound to the link tag that contains the information.

Given (1), the information needs to be embedded in the HTML markup.
Given (2), the information needs to be tied to the specific link tag.

For example:

  http://op.example.com/openid1";>
  http://op.example.com/openid2";>

vs.
  http://op.example.com/openid1";>
  http://op.example.com/openid2";>
  http://specs.openid.net/auth/2.0";>

While it is true that since the link relationship names changed, the
"openid2" is technically redundant, I think it is much clearer to
everybody what is going on if the link relationship contains the
version number. If the protocol version were to keep changing, I'd
argue for a different solution.

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

RE: DRAFT 11 -> FINAL?

[Recordon, David]

Yeah, I'm not a big fan of openid2.* though it was the simplest method
of fixing up HTML discovery to work with multiple protocol versions.  I
know Josh thought about this more than I did though.

>From what I've seen people do, it is AJAX between your server and
application, then OpenID's checkid_immediate between the server and OP,
with an AJAX response from your server to application.

--David

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Rowan Kerr
Sent: Tuesday, January 30, 2007 2:02 PM
To: specs@openid.net
Subject: Re: DRAFT 11 -> FINAL?

The openid2.* links bug me a little.. but due to no openid.ns being
defined in the 1.x protocol, maybe there is no other way to specify by
HTML discovery that your OP is 2.0 capable. Would it be bad to have a
openid.version link instead?

Also, the spec mentions AJAX interactions, but I don't see how you can
actually use AJAX with OpenID, since none of the responses are in XML
format .. it relies entirely on GET or POST redirection, not to mention
that you have to make cross-domain requests which XmlHttpRequest will
not do without extra security privileges.

(Or am I missing something?)

-Rowan
___
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: DRAFT 11 -> FINAL?

[Rowan Kerr]

The openid2.* links bug me a little.. but due to no openid.ns being
defined in the 1.x protocol, maybe there is no other way to specify by
HTML discovery that your OP is 2.0 capable. Would it be bad to have a
openid.version link instead?

Also, the spec mentions AJAX interactions, but I don't see how you can
actually use AJAX with OpenID, since none of the responses are in XML
format .. it relies entirely on GET or POST redirection, not to
mention that you have to make cross-domain requests which
XmlHttpRequest will not do without extra security privileges.

(Or am I missing something?)

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

Re: OpenID Auth 2.0 security considerations

[Johnny Bufu]

David,

No issues from me - I too believe a non-normative link to a wiki site  
would work best, while keeping the security consideration section we  
have now.

Thanks,
Johnny

On 30-Jan-07, at 12:02 PM, Recordon, David wrote:

> Is there a wiki page that exists to point to? Josh and Johnny, see any
> issues with this?
>
> Also any wording to propose Johannes?
>
> Thanks,
> --David
>
> -Original Message-
> From: Johannes Ernst [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, January 23, 2007 12:57 PM
> To: Recordon, David
> Cc: specs@openid.net
> Subject: Re: OpenID Auth 2.0 security considerations
>
> Given where we are in time, I would suggest to make the smallest  
> amount
> of changes possible to the document, i.e. leave everything as is, just
> add this one link.
>
>
> On Jan 23, 2007, at 11:59, Recordon, David wrote:
>
>> I don't see a problem with that.
>>
>> Would you propose the majority of the security considerations section
>> in the current draft be moved to the wiki?  What would be the balance
>> between spec and wiki page?
>>
>> --David
>>
>> -Original Message-
>> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
>> Behalf Of Johannes Ernst
>> Sent: Monday, January 22, 2007 12:15 PM
>> To: specs@openid.net
>> Subject: OpenID Auth 2.0 security considerations
>>
>> What about a non-normative link from the spec to a place on the wiki
>> where we can collect security considerations for it, and update those
>> in real-time as discussions such as the phishing one progress.
>>
>>
>>
>> ___
>> 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: Tiny RDF Schema at openid.net?

[Benjamin Nowack]

On 30.01.2007 11:56:41, Recordon, David wrote:
>I'm not an RDF/OWL expert, though that looks reasonable to me.  How do
>we deal with Auth 1.x which uses openid.server and openid.delegate
>versus Auth 2.0 which uses openid2.provider and openid2.local_id?
To provide a little bit of background for my initial mail: My objective
is to generate some RDF triples from the OpenID hooks encoded in HTML.
The common practise these days is to create a simple custom transformation
which does the job ("GRDDLing"). However, the existing OpenID format
instructions (link+rel+href) are already compatible with a format 
called eRDF[1], which follows the DC guidelines. We could directly 
re-use eRDF parsers and transformers. What's missing is a namespace
URI for the "openid" prefix in HTML. (It would actually be possibe 
to use eRDF to encode the RDF Schema information directly in the 
HTML version of the OpenID specs as well. There is no need for a 
separate schema file).

With regard to general RDFS/OWL versioning, there are different options.
If v1, v1.1, and v2 form *one* evolving spec with mostly overlapping 
terms (i.e. the semantics -and maybe even the naming- of many v2 terms
is identical to those from pior versions), the trend seems to be to 
stick to a single namespace URI and to use OWL constructs to indicate
deprecated terms before they are removed from the spec. If v2 is really
different from v1 or you want a clean start, the specs should be in 
two schema files with different namespace URIs, maybe with links from
the new one to the old (there are things like "sameAs" and 
"equivalentProperty" in OWL).

Different namespaces also means that the HTML hook prefixes should 
reflect that, i.e. "openid.server openid2.provider" is fine, 
"openid.server openid.provider" would not allow the definition of 
different namespaces URIs for the two terms in eRDF. So, with a new
prefix (openid2), there should probably also be a new spec file.

My suggestion would be to create two files, with the v2 one linking
to the v1 one via owl:equivalentProperty (if the new terms are
equivalent, that is)


Ugh, I hope that was more helpful than confusing..

Ben


[1] http://research.talis.com/2005/erdf/wiki/Main/RdfInHtml

>
>--David
>
>-Original Message-
>From: Benjamin Nowack [mailto:[EMAIL PROTECTED] 
>Sent: Monday, January 29, 2007 10:13 AM
>To: Recordon, David; Scott Kveton; specs@openid.net
>Cc: [EMAIL PROTECTED]
>Subject: RE: Tiny RDF Schema at openid.net?
>
>On 29.01.2007 07:53:15, Recordon, David wrote:
>>I'd be happy to do it; I think we were talking about using 
>>xmlns.openid.net/foo as a format.
>Awesome :)
>
>>I think the next step would be sending a copy of the RDF file for 
>>people here to look over. :)
>
>I've attached a draft which contains already some nice2haves (e.g.
>the OWL and isDefinedBy bits which may be helpful but are not strictly
>necessary), I'm not 100% sure about the prose, and I guess DanC will
>have a comment or two as well.
>
>(The resource/about/ID attributes work similar to HTML's href/id, they
>use the doc's URL as base, i.e. if the file was published at
>, the full term URIs would be
> etc.)
>
>[[[
>
>http://www.w3.org/1999/02/22-rdf-syntax-ns#";
>  xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#";
>  xmlns:owl="http://www.w3.org/2002/07/owl#";>
>
>  
>OpenID Authentication Schema
>2007-01-29
>
>  A basic schema for core OpenID authentication terms.
>
>  
>  
>  
>rdf:resource="http://www.w3.org/2002/07/owl#ObjectProperty"/>
>server
>
>  The OpenID Identity Provider to be used for authentication.
>
>rdf:resource="http://openid.net/specs/openid-authentication-1_1.html"; />
>  
>  
>  
>rdf:resource="http://www.w3.org/2002/07/owl#ObjectProperty"/>
>delegate
>
>  The delegated OpenID Identifier to be used for authentication.
>
>rdf:resource="http://openid.net/specs/openid-authentication-1_1.html"; />
>  
>
>
>]]]
>
>Best,
>Ben
>
>
>>
>>Thanks,
>>--David
>>
>>-Original Message-
>>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On 
>>Behalf Of Scott Kveton
>>Sent: Monday, January 29, 2007 7:42 AM
>>To: Benjamin Nowack; specs@openid.net
>>Cc: [EMAIL PROTECTED]
>>Subject: Re: Tiny RDF Schema at openid.net?
>>
>>With just a quick look at this, it seems like a good idea.  I'd like to
>
>>see it happen somehow.
>>
>>Anybody see any problems with doing this?
>>
>>- Scott
>>
>>
>>
>>
>>
>>On 1/29/07 2:13 AM, "Benjamin Nowack" <[EMAIL PROTECTED]> wrote:
>>
>>> 
>>> 
>>> Hi,
>>> 
>>> I was wondering if you guys could be persuaded to host a little RDF 
>>> Schema file on the openid.net site. As far as I can tell, there is 
>>> great support for OpenID among SemWeb folks as it can be combined 
>>> with
>>
>>> things like FOAF for all sorts of cool applications.
>>> 
>>> People recently started to write RDF extractors for the OpenID hooks 
>>> embedded in HTML (openi

RE: DRAFT 11 -> FINAL?

[Recordon, David]

Thanks, fixed the HTML terminology  as a start.
http://openid.net/svn/diff.php?repname=specifications&path=%2Fauthentication%2F2.0%2Ftrunk%2Fopenid-authentication.xml&rev=292&sc=1

--David 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Claus Färber
Sent: Saturday, January 20, 2007 10:15 AM
To: specs@openid.net
Subject: Re: DRAFT 11 -> FINAL?

Dick Hardt <[EMAIL PROTECTED]> schrieb/wrote:
> Are there any more issues with this specification:
>   http://openid.net/specs/openid-authentication-2_0-11.html

> Can we make this final?

Ok, here are the problems I found during a quick review:

-
| 4.1.1.  Key-Value Form Encoding
|
| A message in Key-Value form is a sequence of lines. Each line begins 
| with a key, followed by a colon, and the value associated with the 
| key. The line is terminated by a single newline (UCS codepoint 10, 
| "\n"). A key or value MUST NOT contain a newline and a key also MUST 
| NOT contain a colon.

While it's ok for keys to have a limited alphabet, not allowing them in the 
value may be a problem for future extensions (say, if AX wants to transfer a 
multiline postal address).

I don't think it's a good idea to invent a new format here. What's wrong with 
URI percent-encoding, which has to be implemented by OpenID software anyway?

OpenID could even use application/x-www-form-urlencoded for simple exchanges 
and multipart/form-data (HTML 4.01, section 17.13.4) for some aspects of AX 
(say, e.g. a JPEG photo).

Also, section 5.1.2 says that the response SHOULD be labelled as
"text/plain":

| 5.1.2.  Direct Response
|
| The body of a response to a Direct Request (Direct Request) consists 
| of an HTTP Response body in Key-Value Form (Key-Value Form Encoding).
| The content-type of the response SHOULD be "text/plain".

Together with section 4.1.1, this is incompatible with HTTP, the spec of which 
says (RFC 2616, section 3.7.1):

> When in canonical form, media subtypes of the "text" type use CRLF as 
> the text line break. HTTP relaxes this requirement and allows the 
> transport of text media with plain CR or LF alone representing a line 
> break when it is done consistently for an entire entity-body. HTTP 
> applications MUST accept CRLF, bare CR, and bare LF as being 
> representative of a line break in text media received via HTTP.

There are two options: Don't use a "text/*" subtype or bring the OpenID spec in 
line with HTTP (i.e. treat CRLF, CR and LF the same). If the later is chosen, 
"text/plain" must also be changed to "text/plain with a charset of UTF-8" as 
the default for HTTP is "ISO-8859-1" (RFC 2616, section 3.7.1).

-

| 5.1.2.1.  Successful Responses
|
| A server receiving a valid request MUST send a response with an HTTP 
| status code of 200.

That may be incompatible with some HTTP caching/conditional response features. 
There is a slight chance that, for example, a 206 code might also be 
appropriate in some situations

-

| 5.1.2.2.  Error Responses
|
| If a request is malformed or contains invalid arguments, the server 
| MUST send a response with a status code of 400.

This is incompatible with RFC 2616, which would also allow different error 
codes depending on the situation.

What about "... MUST send a response with an appropriate HTTP status code such 
as 400 (Bad Request)".

| The response body MUST be a Key-Value Form (Key-Value Form Encoding) 
| message with the following fields:
...
| *error
| Value: A human-readable message indicating the cause of the error.

What about different languages?

This is actually tricky. The Accept-Language header from the user is not 
available to the OP if it is contacted by the RP directly, so the OP can't 
choose an appropriate language.

Note that RFC 2277 (= BCP 18) says:

> 4.2.  Requirement for language tagging
>
> Protocols that transfer text MUST provide for carrying information 
> about the language of that text.

While this technically isn't binding for a non-IETF spec, it's still an 
extremly good idea.

Same problem in 5.2.3 and 8.2.4.

-

| 7.3.3.  HTML-Based Discovery
|
| HTML-Based discovery MUST be supported by Relying Parties. HTML-Based 
| discovery is only usable for discovery of Claimed Identifiers. OP 
| Identifiers must be XRIs or URLs that support XRDS discovery.
|
| To use HTML-Based discovery, an HTML document MUST be available at the 
| URL of the Claimed Identifier. In the HEAD section of the document:

It seems that it has been unclear to some implementers what "HEAD section" 
means. This is not surprising as the correct term is "HEAD element" (HTML 4.01, 
section 3.2.1).

|A  tag MUST be included with attributes "rel" set to
|"openid2.provider" and "href" set to an OP Endpoint URL
|A  tag MAY be included with attributes "rel" set to
|   "openid2.local_id" and "href" set to the end user's OP-Local
|   Identifier

These should read "LINK element", not " tag".

| The protocol version when HTML discove

RE: OpenID Auth 2.0 security considerations

[Recordon, David]

Is there a wiki page that exists to point to? Josh and Johnny, see any
issues with this?

Also any wording to propose Johannes?

Thanks,
--David

-Original Message-
From: Johannes Ernst [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, January 23, 2007 12:57 PM
To: Recordon, David
Cc: specs@openid.net
Subject: Re: OpenID Auth 2.0 security considerations

Given where we are in time, I would suggest to make the smallest amount
of changes possible to the document, i.e. leave everything as is, just
add this one link.


On Jan 23, 2007, at 11:59, Recordon, David wrote:

> I don't see a problem with that.
>
> Would you propose the majority of the security considerations section 
> in the current draft be moved to the wiki?  What would be the balance 
> between spec and wiki page?
>
> --David
>
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On 
> Behalf Of Johannes Ernst
> Sent: Monday, January 22, 2007 12:15 PM
> To: specs@openid.net
> Subject: OpenID Auth 2.0 security considerations
>
> What about a non-normative link from the spec to a place on the wiki 
> where we can collect security considerations for it, and update those 
> in real-time as discussions such as the phishing one progress.
>
>
>
> ___
> 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: HTML parsing in HTML-based discovery

[Recordon, David]

Would it be worthwhile to write-up the steps the JanRain parser uses and
see what from it could be included in the OpenID spec to help out
implementors?

--David 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Josh Hoyt
Sent: Friday, January 26, 2007 1:07 PM
To: Martin Atkins
Cc: specs@openid.net
Subject: Re: HTML parsing in HTML-based discovery

On 1/26/07, Martin Atkins <[EMAIL PROTECTED]> wrote:
> And, in theory, the OpenID spec could add additional restrictions to 
> "fix" the above problems.
>
> Whether it should or not is of course up for debate; I'd be interested

> to hear from Brad Fitzpatrick and JanRain's developers who are 
> responsible for the most-used implementations currently using regex 
> parsing. Why didn't you guys use an HTML parser? I assume there must 
> have been a reason.

While our parser [1] is implemented using regular expressions, I don't
think it's what most people mean when they say "parsing with regexps."

The reason that (most of) the JanRain libraries don't use an HTML parser
is because I was afraid that "loose" parsing of HTML could lead to
OpenID discovery markup being recognized in parts of the document other
than the head, leading to vulnerabilities where someone could hijack a
URL by e.g. adding a malicious comment to a blog.

When implementing this parser, I tried to be aware of both the varied
markup that exists across the Web and the security implications of
different parsing strategies. In short, the parser tries to recognize
any OpenID markup that is unambiguously in the  of an HTML
document and reject anything else. If you're interested in the details,
read the comments at the top of the file (again, [1])

The parser does not work for some valid XHTML cases, most notably using
an explicit XML namespace for the XHTML tags. It also does not deal with
some cases of valid HTML 4. [2] I am sure that there are other cases in
which valid markup is not recognized. My implementation and design
strategy was to implement something that is immune to the attacks that I
could conceive and work for the vast majority of the cases that exist in
the wild.

Ironically, another reason that we implemented this parser instead of
using an (X)HTML parsing library is that according to the spec, only
certain entities should be processed in the  tag's attributes, and
a real (X)HTML parser would process all of the entities. It's arguable
whether processing the entities is right or wrong, because the user who
marked up the page is violating the spec, but I figured that by
following the spec exactly, the users who put in this markup would have
a more consistent experience (i.e. their markup would be broken for all
libraries rather than accepted by some and rejected by
others)

In an ideal world, we'd be able to specify that the document was e.g.
valid XHTML and just use a nice, strict parser on it. The reality of the
situation forces us to deal with the markup that's out there, which
leads to trade-offs, no matter how we choose to deal with that markup.

Josh

1.
http://www.openidenabled.com/resources/darcsweb?r=python-openid;a=headbl
ob;f=/openid/consumer/parse.py
2.
http://www.intertwingly.net/blog/2006/12/28/Unobtrusive-OpenID#c11674043
28
___
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: Tiny RDF Schema at openid.net?

[Recordon, David]

I'm not an RDF/OWL expert, though that looks reasonable to me.  How do
we deal with Auth 1.x which uses openid.server and openid.delegate
versus Auth 2.0 which uses openid2.provider and openid2.local_id?

--David

-Original Message-
From: Benjamin Nowack [mailto:[EMAIL PROTECTED] 
Sent: Monday, January 29, 2007 10:13 AM
To: Recordon, David; Scott Kveton; specs@openid.net
Cc: [EMAIL PROTECTED]
Subject: RE: Tiny RDF Schema at openid.net?

On 29.01.2007 07:53:15, Recordon, David wrote:
>I'd be happy to do it; I think we were talking about using 
>xmlns.openid.net/foo as a format.
Awesome :)

>I think the next step would be sending a copy of the RDF file for 
>people here to look over. :)

I've attached a draft which contains already some nice2haves (e.g.
the OWL and isDefinedBy bits which may be helpful but are not strictly
necessary), I'm not 100% sure about the prose, and I guess DanC will
have a comment or two as well.

(The resource/about/ID attributes work similar to HTML's href/id, they
use the doc's URL as base, i.e. if the file was published at
, the full term URIs would be
 etc.)

[[[

http://www.w3.org/1999/02/22-rdf-syntax-ns#";
  xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#";
  xmlns:owl="http://www.w3.org/2002/07/owl#";>

  
OpenID Authentication Schema
2007-01-29

  A basic schema for core OpenID authentication terms.

  
  
  
http://www.w3.org/2002/07/owl#ObjectProperty"/>
server

  The OpenID Identity Provider to be used for authentication.

http://openid.net/specs/openid-authentication-1_1.html"; />
  
  
  
http://www.w3.org/2002/07/owl#ObjectProperty"/>
delegate

  The delegated OpenID Identifier to be used for authentication.

http://openid.net/specs/openid-authentication-1_1.html"; />
  


]]]

Best,
Ben


>
>Thanks,
>--David
>
>-Original Message-
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On 
>Behalf Of Scott Kveton
>Sent: Monday, January 29, 2007 7:42 AM
>To: Benjamin Nowack; specs@openid.net
>Cc: [EMAIL PROTECTED]
>Subject: Re: Tiny RDF Schema at openid.net?
>
>With just a quick look at this, it seems like a good idea.  I'd like to

>see it happen somehow.
>
>Anybody see any problems with doing this?
>
>- Scott
>
>
>
>
>
>On 1/29/07 2:13 AM, "Benjamin Nowack" <[EMAIL PROTECTED]> wrote:
>
>> 
>> 
>> Hi,
>> 
>> I was wondering if you guys could be persuaded to host a little RDF 
>> Schema file on the openid.net site. As far as I can tell, there is 
>> great support for OpenID among SemWeb folks as it can be combined 
>> with
>
>> things like FOAF for all sorts of cool applications.
>> 
>> People recently started to write RDF extractors for the OpenID hooks 
>> embedded in HTML (openid.server/delegate). As these hooks are in line

>> with the Dublin Core guidelines [1], there are even multiple ways to 
>> do this. The only thing we're missing for more widespread use is an 
>> agreed-on namespace URI for the core openID terms ("server" and 
>> "delegate"). And ideally this would be an openid.net one. So here is 
>> my request: any chance we could put a little RDF Schema file on the 
>> openid server? We would of course provide the file (it'd be just 5-10

>> lines of XML), and the actual URL/path doesn't really matter. An 
>> alternative could be to host it in some other stable URI space, Dan 
>> Connolly (CC'd) might be able to provide one at w3.org, not sure. It 
>> would be cool to get your blessing either way, though.
>> 
>> 
>> Cheers in advance for perhaps considering it, Ben
>> 
>> --
>> Benjamin Nowack
>> 
>> Kruppstr. 100
>> 45145 Essen, Germany
>> http://www.bnode.org/
>> 
>> 
>> [1] http://www.dublincore.org/documents/dcq-html/
>> 
>> ___
>> specs mailing list
>> specs@openid.net
>> http://openid.net/mailman/listinfo/specs
>> 
>
>___
>specs mailing list
>specs@openid.net
>http://openid.net/mailman/listinfo/specs
>
>
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs