Re: SREG namespace URI rollback

[Johnny Bufu]

On 2-Apr-07, at 6:06 PM, Recordon, David wrote:

> Sure, though I think there has also been a desire to do a bit of an

Are we in agreement then (about 1.0 and 1.1 sharing the same type URI)?

I went ahead and implemented SREG in openid4java, and exposed it in  
such a way that the users won't have to know about all these v1.0 /  
1.1 details. But in order for that to work and my implementation to  
be compliant, the type URI of SREG 1.1 needs to change as proposed by  
Josh in the next (final?) draft.

Thanks,
Johnny

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

Re: Label replacing Key

[Douglas Otis]

On Sat, 2007-04-07 at 18:22 -0700, Douglas Otis wrote:

Oops.

4.1.  Protocol Messages (second paragraph)

> Messages MUST NOT contain multiple values within the same field name.

Messages MUST NOT contain message parameters with the same field name.

-Doug



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

Re: Label replacing Key

[Douglas Otis]

On Sat, 2007-04-07 at 10:30 -0700, Josh Hoyt wrote:
> On 4/7/07, Douglas Otis <[EMAIL PROTECTED]> wrote:
> > This would then require all locations that use the term "key" when
> > referring to a field label to be changed to "label"
> 
> -1
> 
> If it needs to be changed, Martin's suggestion of "name" instead is much 
> better.

Okay, but the use of name should be explicitly defined.

The use of just name creates some ambiguity with the "name" attribute.
Review sections 5.2.2. and 7.1.. Or with DNS name in 9.2. and and 12.

The OpenID draft refers to the field name and to the right most labels
of the field name as being synonymous with "key".  This short-hand
should be clearly defined using other terms.

Key is not a term used in w3.org definitions, that tend to use the all
encompassing "keyword" instead.  Key normally refers to keyboard keys,
or cryptographic keys.  Unfortunately "Name" does not permit an explicit
definition due to conflicts within the spec and the ambiguity when using
subordinate naming elements.  

note:

 rfc2822 (2.2.) for email defines roughly the same structure as "field
 name" followed by a "field body".

 rfc1034 (3.1.) for dns defines names as a tree structure of labels.


How about:

Additional terms clarified within the terminology section such as:

---
2.  Terminology
...

Attribute:

 Attributes hold associated properties of HTML elements and may have
 values.  Attribute/value pairs appear before the final ">" of an
 element's start tag. Any number of (legal) attribute value pairs,
 separated by spaces, may appear in any order within an element's
 start tag.
 
Message Parameter:

 Message Parameters are in Field Name-Value Form as a sequence of
 lines terminated by a single newline (UCS codepoint 10, "\n"). Each 
 line begins with  a field name, followed by a colon, and a single value
 or a comma separated list associated with the field name.

Short Name:

 A Short Name is resolved by removing or assuming an "openid" prefix
 of an associated Field Name.
  
---

---
4.1.  Protocol Messages

The OpenID Authentication protocol messages parameters are mappings of
plain-text field names to plain-text field values. The field names and
field values permit the full unicode character set (UCS). When the field
names and field values need to be converted to/from bytes, they MUST be
encoded using UTF-8 (Yergeau, F., “UTF-8, a transformation format of
Unicode and ISO 10646,”) [RFC3629]. 

Messages MUST NOT contain multiple values within the same field name. 

Throughout this document, all OpenID message parameters are REQUIRED,
unless specifically marked as OPTIONAL. 

 
4.1.1.  Field Name-Value Form Encoding

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

Additional characters, including whitespace, MUST NOT be added before or
after the colon or newline. The message MUST be encoded in UTF-8 to
produce a byte string. 

A Short Name-Value Form of encoding is used for signature calculation
and for direct responses(Direct Response) to Relying Parties. See
sections 5.1.2, 5.1.2.2, 6.1, 8.2.1, 8.2.2, 8.2.3, 8.2.4, 11.4.2.2. 
 
---

This change requires all locations that use the term "key" when
referring to a field name to be changed to "field name".  When referring
to a derived short name to be changed to "short name".


-Doug

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

Re: PROPOSAL schema.openid.net for AX (and other extensions)

[Dick Hardt]

On 6-Apr-07, at 6:46 PM, Recordon, David wrote:

> You also could go buy idschemas.org and start there, to be migrated
> later if need be.  I don't really care who owns the domain since the
> wider community will hold the owner to do the right thing, though I'd
> imagine donating it to Identity Commons to hold would be an easy thing
> to do.

I still see no reason to not start using openid.net for the OpenID  
Community to start working with.

>
> Yes, VeriSign is activly developing OpenID 2.0 code in Java
> (http://code.google.com/p/joid/) and evaluating if/when we'll be
> implementing Attribute Exchange alongside Simple Registration.

I'd welcome feedback, suggestions and contributions from VeriSign  
individuals if/when they work with Attribute Exchange!

btw: for someone that preaches not reinventing the wheel, why is  
VeriSign working on a new Java implementation instead of working with  
one of the existing ones like OpenID4Java?

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

Re: Moving AX Forward (WAS RE: SREG namespace URI rollback)

[Johnny Bufu]

On 7-Apr-07, at 3:56 AM, Martin Atkins wrote:
> On the other hand, I also think it's a good idea not to modularize too
> early: until there's some implementation experience, it's hard to say
> with certainty what parts make sense as distinct modules. I'm not that
> familiar with the AX stuff yet, but my gut feeling is that it'd be a
> good idea for someone to make an experimental implementation to get  
> some
> implementation experience and then it'll probably be a lot more clear
> where the articulation points are that make spec modularization
> worthwhile. There's little point in debating it at this early  
> stage, in
> my opinion.

We did just that - openid4java supports Attribute Exchange (i.e the  
"transport" layer for attributes), but nothing about the metadata.  
Even if the metadata spec were all figured out, my implementation  
would probably hand over the type URI and the attribute value to the  
layer above for consuming it, which would involve looking up the  
metadata info if necessary.

Josh just started implementing AX [1] and his thoughts were along the  
same lines.


Johnny


[1] http://openid.net/pipermail/specs/2007-April/001520.html
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

FW: [Idschemas] FYI Schemat Consumer

[Recordon, David]

This seems relevant to the current AX discussion.


 -Original Message-
From:   Mark Wahl [mailto:[EMAIL PROTECTED]
Sent:   Saturday, April 07, 2007 02:34 PM Pacific Standard Time
To: ID Schemas
Subject:[Idschemas] FYI Schemat Consumer


Today we (Informed Control Inc.) packaged up the source code for
Schemat Consumer, a small, open source, proof of concept library
for attribute type metadata parsing.

The Schemat Consumer provides applications in an identity metasystem
with a simple Java API for retrieving the metadata of URI-named attribute
types.  (It is intended for applications which are not already RDF-aware,
and just need to get additional details on unrecognized identity attributes.)

SchematConsumer sc = SchematConsumer.getInstance();
// ...
IAttributeTypeMetadataClasses iatmc =
  sc.findAttributeTypeMetadataFromSubjectUri(new URI(attribute_type));
CommonAttributeTypeMetadata c = new CommonAttributeTypeMetadata(iatmc);

The CommonAttributeTypeMetadata implements get-methods for a subset of
the metadata elements defined by W3C, Dublin Core, Higgins and OpenID AX:

String label = c.getLabel(); // get display label for the attribute type
String comment = c.getComment(); // get display comment for the attribute type
List seealso = c.getSeeAlsoUriStringsList(); // get URIs of 'see also'
boolean isequiv = c.isEquivalentToUri(another_attribute_type); // test are two 
attribute types equivalent?
List acq_uris = c.getAcquisitionUriStringsList(); // get URIs where to acquire 
values of this attribute
List auth_uris = c.getAuthorityUriStringsList(); // get URIs of authorities for 
this attribute
String example = c.getValueExampleString(); // get String example value of this 
attribute
HigginsValuePropertyDatatype v = c.getHigginsValuePropertyDatatype();
if (v != null) {
String pattern = v.getPatternString();  // get regular expression of value 
syntax
}

Future versions are anticipated to implement the full set of Identity Schemas
metadata in http://idschemas.idcommons.net/moin.cgi/MetaData

Applications can also request an XHTML fragment describing the attribute, or an
entire schema collection of attributes.

Schemat Consumer wraps the Jakarta HTTP core client library and the HP Labs 
Jena ARP2
RDF parser. Currently it implements the http and file URI schemes to
retrieve the RDF/XML encoding of metadata, and has a cache of metadata to avoid
frequent retrievals and to support offline operations.

More info at
http://www.ldap.com/1/spec/schema/ont.shtml
http://www.ldap.com/1/commentary/wahl/20070407_01.shtml

Mark Wahl
Informed Control Inc.

___
Idschemas mailing list
[EMAIL PROTECTED]
http://mail.idcommons.net/cgi-bin/mailman/listinfo/idschemas
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: Label replacing Key

[Josh Hoyt]

On 4/7/07, Douglas Otis <[EMAIL PROTECTED]> wrote:
> This would then require all locations that use the term "key" when
> referring to a field label to be changed to "label"

-1

If it needs to be changed, Martin's suggestion of "name" instead is much better.

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

Authentication Protocols for Non-browser Apps

[Martin Atkins]

Today I've re-written the HTTP Authentication bindings I previously 
specified to support the use of associations rather than using dumb mode 
exclusively. The new specification more closely mirrors the 
browser-based OpenID Authentication protocol and wherever possible just 
adapts it to go over the different transport.

 

That protocol alone allows a non-human agent to authenticate as itself 
when acting as its own OP. This means that it is able to maintain its 
own associations and can compute its own assertion signatures.

I've drafted a second protocol that would allow the above protocol to be 
used for human users that use a traditional OP:

 

This does unfortunately require special support from the OP. Given that 
support for this protocol or another protocol like it is very important 
for non-browser app authentication I'm wondering if perhaps it should be 
rolled into the core OpenID Authentication 2.0 spec; as it currently 
stands, it's really just a different interface to what the OP already 
does, so it wouldn't be a massive extra implementation burden, though 
there are some remaining issues I've outlined in that wiki page that 
will certainly need to be addressed first.

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

Label replacing Key

[Douglas Otis]

On Sat, 2007-04-07 at 08:58 -0700, Douglas Otis wrote:

Oops.  I missed two references to keys.

---
4.1.  Protocol Messages
The OpenID Authentication protocol messages are mappings of plain-text
labels to plain-text values. The labels and values permit the full
Unicode character set (UCS). When the labels and values need to be
converted to/from bytes, they MUST be encoded using UTF-8(Yergeau, F.,
“UTF-8, a transformation format of Unicode and ISO 10646,” .)
[RFC3629]. 

Messages MUST NOT contain multiple parameters with the same label. 

Throughout this document, all OpenID message parameters are REQUIRED,
unless specifically marked as OPTIONAL. 


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

Additional characters, including whitespace, MUST NOT be added before or
after the colon or newline. The message MUST be encoded in UTF-8 to
produce a byte string. 

Label-Value Form encoding is used for signature calculation and for
direct responses(Direct Response) to Relying Parties.  For brevity, this
specification may refer to sub-components of the label.  For example,
the field label "openid.mode" may be referenced as just "mode".  

---

This would then require all locations that use the term "key" when
referring to a field label to be changed to "label" 

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

Re: password-free login without SSL and OP reliance (an anti-phishing solution)

[Douglas Otis]

On Sat, 2007-04-07 at 11:43 +0100, Martin Atkins wrote:
> Douglas Otis wrote:
> > 
> > For clarity, OpenID Authentication 2.0 - Draft 11 "4.1.1. Key-Value  
> > Form Encoding" should change to something like "Keyword-Value Form  
> > Encoding".  Avoid using the word "key" to mean field or label.  This  
> > will cause confusion.
> > 
> 
> While I believe that "key-value pairs" is a common enough term that 
> confusion is unlikely by any knowledgeable developer, I suggest that if 
> it be changed it be changed to "name-value form encoding", since I think 
> this is more commonly used than "keyword-value".

For me, he term key-value was a bit confusing because it was not
explicit.

This term "key" currently refers to either fields or sub-fields in
sections- 4.1.2., 5.1.1., 5.1.2., 5.1.2.2., 5.2., 7.1., 10.1., 11.2.,
11.4.1., 11.4.2.1., 14.2., 15.1.2.

There are sub-fields identified as "name" where the term name would get
confusing in section 5.2.2., 7.1., 9.2., 12. and A.5. 

How about this:
---
4.1.  Protocol Messages
The OpenID Authentication protocol messages are mappings of plain-text
labels to plain-text values. The keys and values permit the full Unicode
character set (UCS). When the keys and values need to be converted
to/from bytes, they MUST be encoded using UTF-8(Yergeau, F., “UTF-8, a
transformation format of Unicode and ISO 10646,” .) [RFC3629]. 

Messages MUST NOT contain multiple parameters with the same label. 

Throughout this document, all OpenID message parameters are REQUIRED,
unless specifically marked as OPTIONAL. 


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

Additional characters, including whitespace, MUST NOT be added before or
after the colon or newline. The message MUST be encoded in UTF-8 to
produce a byte string. 

Label-Value Form encoding is used for signature calculation and for
direct responses(Direct Response) to Relying Parties.  For brevity, this
specification may refer to sub-components of the label.  For example,
the field label "openid.mode" may be referenced as just "mode".  


---

This would then require all locations that use the term "key" when
referring to a field label to be changed to "label".

-Doug





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

Re: Moving AX Forward (WAS RE: SREG namespace URI rollback)

[Martin Atkins]

Johnny Bufu wrote:
> 
> These two seem to have been the rationale of the recent discussions  
> about splitting the OpenID spec into core/discovery/etc., which  
> seemed to make sense to a number of people (I'm just not sure if it's  
> worth / good tactical move at this stage).
> 

I tend to think it's a good idea to modularize specifications in the 
same way as you'd probably modularize the implementation. This is why[1] 
I was pushing for separate Auth / service discovery stuff: the service 
discovery stuff is obviously useful for things other than auth, and 
there are *already* separate libraries for it (Service::Yadis and 
friends), so it makes sense for it to be given as a separate specification.

On the other hand, I also think it's a good idea not to modularize too 
early: until there's some implementation experience, it's hard to say 
with certainty what parts make sense as distinct modules. I'm not that 
familiar with the AX stuff yet, but my gut feeling is that it'd be a 
good idea for someone to make an experimental implementation to get some 
implementation experience and then it'll probably be a lot more clear 
where the articulation points are that make spec modularization 
worthwhile. There's little point in debating it at this early stage, in 
my opinion.

-

[1] One of the reasons, anyway. The other reason was to reach a 
situation where the OpenID Authentication specification can largely 
reference only other specifications under the OpenID umberella, which 
means bringing the "Yadis" tech into OpenID land (which it basically 
already is, despite the distinct brand) and defining a subset of the 
XRDS schema to avoid referencing the entirety of XRI Resolution 2.0, 
which contains lots of stuff that is not necessary for OpenID and 
related tech.

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

Re: Moving AX Forward (WAS RE: SREG namespace URI rollback)

[Martin Atkins]

Johnny Bufu wrote:
> 
> I believe a key difference here is between what people would be  
> willing to do, and what people actually (will) do. For example:
> 
> - I would be willing to go to a rugby game, but I don't know if any  
> of my friends are going, so I probably won't go
> - most of my friends who like rugby may be thinking and acting the  
> same way, or
> - most of my friends would go if they knew rugby, but they haven't  
> discovered it yet.
> 

 From a purely selfish point of view, I'm happy for this discussion to 
take part on the specs list just so I don't have to join and configure 
YET ANOTHER MAILING LIST(tm).

:)

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

Re: password-free login without SSL and OP reliance (an anti-phishing solution)

[Martin Atkins]

Douglas Otis wrote:
> 
> For clarity, OpenID Authentication 2.0 - Draft 11 "4.1.1. Key-Value  
> Form Encoding" should change to something like "Keyword-Value Form  
> Encoding".  Avoid using the word "key" to mean field or label.  This  
> will cause confusion.
> 

While I believe that "key-value pairs" is a common enough term that 
confusion is unlikely by any knowledgeable developer, I suggest that if 
it be changed it be changed to "name-value form encoding", since I think 
this is more commonly used than "keyword-value".


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