Re: Comments on Auth 2.0 - Pre-Draft 11

[Johannes Ernst]

Sounds good.

On Dec 14, 2006, at 16:28, Josh Hoyt wrote:

> On 12/11/06, Johannes Ernst <[EMAIL PROTECTED]> wrote:
>> >> 7.1 Initiation
>> >>
>> >> Given recent discussions on logo and User Experience, this needs
>> >> to be different. Instead of:
>> >>
>> >>>  To initiate OpenID Authentication, the Relying Party SHOULD
>> >>> present the end user with a form that has a field for entering an
>> >>> Identifier.
>> >>>
>> >>> It is RECOMMENDED that a Relying Party place the OpenID logo at
>> >>> the beginning of the form field where the end user enters their
>> >>> Identifier. This aides in end user recognition that they can use
>> >>> an OpenID enabled Identifier at the Relying Party.
>> >>
>> >> Better:
>> >>
>> >>> This document does not define a user experience. It is
>> >>> RECOMMENDED that implementors follow the OpenID user experience
>> >>> if and when such an OpenID user experience has been defined in a
>> >>> separate document.
>>
>> Proposed resolution?
>
> I've taken out the logo recommendation and left it with an input field
> in a form with the appropriate "name" attribute. The user-experience
> document won't contradict *that* much, and it's a technical necessity
> (for e.g. smart software agents to detect the login field).
>
> See http://openid.net/svn/listing.php?repname=specifications&path=% 
> 2F&rev=212&sc=1
>
> Josh

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

Re: Consistency of negative responses to checkid_immediate requests

[Johannes Ernst]

The internet has only standards worth the name that were only  
supposed to last for a short time. I think past experience shows that  
our assumption needs to be "everything stays around forever".

We haven't even solved the \n\a problem yet.

On Dec 14, 2006, at 16:14, Josh Hoyt wrote:

> On 12/14/06, Johnny Bufu <[EMAIL PROTECTED]> wrote:
>> On 14-Dec-06, at 12:13 AM, Josh Hoyt wrote:
>>> On 12/13/06, Martin Atkins <[EMAIL PROTECTED]> wrote:
 Josh Hoyt wrote:
>
> It's confusing to me make the failure response to an immediate  
> mode
> request be "id_res", especially if that is not the failure  
> response
> for setup mode. I can't see a reason that they can't both use the
> "cancel" response to indicate that the OP or end user do not  
> wish to
> complete the transaction.
>
> This is a very minor change, but it will make the spec simpler.
>

 I think the RP will want to do something different in these two
 cases.
>>>
>>> That's true, but the RP will probably need to handle the success  
>>> case
>>> differently for immediate mode anyway (e.g. it will have to do  
>>> AJAX to
>>> update the page) so I expect it to have a specific return_to URL for
>>> immediate requests. Since using a different return_to is trivial, I
>>> prefer the consistency of negative responses.
>>
>> The current / v1 modes will need to be mentioned in the compatibility
>> section, and also implemented. Not sure if this simplification will
>> then still be worth.
>
> That's a good point. I guess it comes down to how long OpenID 1.1
> support will be necessary. If it's a long time (effectively forever)
> then it's definitely not worth it. If it's a relatively short period
> of time, then I think it is worth it for the cleaner spec.
>
> Unless someone agrees that it'd be worth it, I'll leave it alone.
>
> Josh
> ___
> 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: Comments on Auth 2.0 - Pre-Draft 11

[Johannes Ernst]

And I had responded:

In which case, I will "attempt" to be satisfied ;-)


On Dec 14, 2006, at 16:35, Josh Hoyt wrote:

> Oops, forgot to copy the list...
>
> On 12/14/06, Josh Hoyt <[EMAIL PROTECTED]> wrote:
>> On 12/11/06, Johannes Ernst <[EMAIL PROTECTED]> wrote:
>> > >> 9.1. Request Parameters
>> ...
>> > >>> Note: If an OP-SPecific Identifier is not supplied, the
>> > >>> Claimed Identifier is considered to have the same as the OP-
>> > >>> Specific Identifier. If neither value is present, the assertion
>> > >>> is not about an identifier, and will contain other  
>> information in
>> > >>> its payload, using extensions (Extensions).
>> > >
>> > > This doesn't seem right; I read your text like this:
>> > >
>> > >> "If an OP-Specific Identifier is not supplied"
>> > > and therefore openid.identity = "http://openid.net/
>> > > identifier_select/2.0"
>> > >> "the Claimed Identifier is considered to have the same as the  
>> OP-
>> > >> Specific Identifier."
>> > > openid.claimed_id = "http://openid.net/identifier_select/2.0";
>> > >
>> > > Which is fine, but doesn't cover the remaining cases, i.e. when
>> > > Claimed Identifiers / OP-Specific Identifiers *are* supplied.
>> > >
>> > > The original / current wording does cover these cases, albeit I
>> > > admit it is not very easy to read.
>> >
>> > So I modify my request to modify the wording in a way that it is
>> > easier to read.
>>
>> Attempted.
>>
>> See http://openid.net/svn/listing.php?repname=specifications&path=% 
>> 2F&rev=201&sc=1
>> and http://openid.net/svn/listing.php?repname=specifications&path=% 
>> 2F&rev=209&sc=1
>>
>> Josh

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

Re: Comments on Auth 2.0 - Pre-Draft 11

[Johannes Ernst]

So you believe that it is tight enough that if you and I implement  
the spec, and somebody types the exact same character string into  
both of our implementations, it will produce the exact same result,  
regardless what the character string was?

That's all I want to accomplish ...

On Dec 14, 2006, at 12:05, Josh Hoyt wrote:

> (I will be addressing the remaining issues that you brought up one  
> at a time)
>
> On 12/11/06, Johannes Ernst <[EMAIL PROTECTED]> wrote:
>> >> 7.2 Normalization
>> >>
>> >> I'm not sure that this -- all of which is OPTIONAL -- should be in
>> >> this document. I would suggest to either make it MANDATORY -- or
>> >> to take it out of this document and refer to a User Experience
>> >> document instead.
>> >>
>> >> The problem is that if the user can type in something incomplete
>> >> at site A, and then types in the same incomplete thing at site B,
>> >> it may work at A but differently at B, which is no good. So either
>> >> make these rules MANDATORY, or delegate them into the user
>> >> experience.
>> >
>> > Normalization is not optional at all - not sure why you understood
>> > it was. Maybe that section needs to be clarified, if you can point
>> > it to us.
>>
>> I am referring to par 1 sentence 2, where is says "needs to" instead
>> of "MUST ... according to the following algorithm".
>> Then to the entire paragraph 2, which says SHOULD.
>>
>> I'd like an algorithm that produces the same normalized identifier
>> from the same entered text string, regardless of site.
>
> I have changed that text from "needs to" to MUST, although I think
> that the sentence before that (The end user's input MUST be normalized
> into an Identifier) is pretty unambiguous.
>
> Paragraph two about normalizing XRIs I think was David's text, so I
> guess I'll wait for his response about that. I think he's on vacation.
>
> Other than the SHOULD for recognizing XRI global context symbols and
> adding the xri:// prefix, I think that the normalization section is
> pretty tight and will not lead to inconsistencies in implementation.
>
> Josh

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

RE: OpenID Exchange

[Recordon, David]

Awesome, glad to see this!  Would be great as Johannes said to see some
flow examples and how you'd see it integrate to do something like
exchange profile data or post a photo on your blog.  Would love to see
this formalized and happy to help however I can!

--David 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Martin Atkins
Sent: Wednesday, December 13, 2006 4:44 AM
To: specs@openid.net
Subject: OpenID Exchange


I have made an early draft of a spec called OpenID Exchange on the wiki:
 

The goal of this protocol is to allow user-accompanied HTTP requests. 
"user-accompanied" means that a consumer makes a request to a service on
behalf of a user and the user reviews and approves the request.

Example applications of this include:
  * Zooomr posting photos into your blog with your one-time approval,
without disclosing your login credentials. [1]
  * Fetching of user profile information.
  * Social networking friendship handshakes. [2]

The protocol should, in theory, be able to act as a transport for any
HTTP-based protocol such as SOAP and AtomAPI, as well as for simple GET
requests. The protocol for "post in my blog" could, for example, just be
an AtomAPI POST request made over OpenID Exchange.

This is still work-in-progress. The spec needs lots of refinement and at
some point I'll have to make a demo or two.

[1] You can still see the results of the demo of my earlier version
of this on LiveJournal, albeit without the pictures:
 

[2] Discussed further in my blog entry on social networking:
 


___
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: [OpenID] Opened IPR Policy Draft

[James A. Donald]

 > > > So the technology is first proposed and described
 > > > on this list, on 2006 December 7, 2006.  It is
 > > > incorporated into the standard and comes to be
 > > > widely used around about, say, 2007 August.  On
 > > > 2007 December 5, 2007, the patent troll has a
 > > > friendly individual inventor file an patent
 > > > application claiming to have invented the
 > > > technology on 2007, december 6.

David Nicol wrote:
 > but the openID standard is more than a year old
 > already.

Changes and enhancements to the openID standard are
patentable.  When the standard was originally proposed,
it was far from clear that it would be widely adopted,
so it is unlikely that anyone patented it in time, so
the original standard is safe from IP.
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: [OpenID] OpenID IPR Policy Draft

[Ben Laurie]

On 12/6/06, Recordon, David <[EMAIL PROTECTED]> wrote:
> Hey guys,
> Been working with Gabe, and others, on starting to draft an IPR Policy
> for OpenID specifications.  We'd appreciate feedback in terms of if what
> is written captures the correct intent of the community?  We realize the
> language isn't technically as tight as it needs to be, though first want
> to make sure it is saying the right thing.  It is largely based on the
> IPR Policy for Microformats.
>
> http://openid.net/wiki/index.php/IPR_Policy

A problem with saying "you MUST offer ... a royalty free license" is
that in order to be open-source-friendly the licence has to be
automatic - otherwise potentially each user of the s/w has to jump
through hoops to get the licence.

>
> Thanks,
> --David
> ___
> general mailing list
> [EMAIL PROTECTED]
> http://openid.net/mailman/listinfo/general
>
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: Off-topic: Re: Comments on Auth 2.0 - Pre-Draft 11

[Eve L. Maler]

As a general point and FWIW, capitalized ("RFC 2119") uses of MUST, 
SHOULD, etc. are meant to make it easy to form testable assertions 
for compliance-checking.  It's best to avoid redundant normative 
spec content, though sometimes repetition or restatement in the 
right places can reinforce a correct interpretation for better 
interop.  And it's best to use non-RFC 2119 ways of conveying 
expectations and best practices precisely in the set of cases where 
something isn't testable (e.g., it's an internal operation of a 
system entity and thus isn't amenable to standardization, or it 
involves some kind of subjective judgment).

If you really mean something normative, using capitals is safest 
even if it seems ugly...  Readers will just want it to be 
consistent, so a final editing pass ideally will include a review of 
this.  If there's some doubt what lowercase versions of the words 
mean, you could add notation wording like what SAML V1.x used:

=
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
specification are to be interpreted as described in IETF RFC 2119 
[RFC 2119]:

 …they MUST only be used where it is actually required for 
interoperation or to limit behavior which has potential for causing 
harm (e.g., limiting retransmissions)…

These keywords are thus capitalized when used to unambiguously 
specify requirements over protocol and application features and 
behavior that affect the interoperability and security of 
implementations. When these words are not capitalized, they are 
meant in their natural-language sense.
=

But this was removed in SAML2, since it was assumed readers know the 
drill.

Richard Mitchell noted thirty years ago that discursive prose is a 
technology.[1]  Technical specs are even more so!  (If you're not 
familiar with the Underground Grammarian, I strongly RECOMMEND his 
Less Than Words Can Say[2]...)

Eve

[1] http://www.sourcetext.com/grammarian/less-than-words-can-say/03.htm
[2] http://www.sourcetext.com/grammarian/index.html

Josh Hoyt wrote:
> On 12/14/06, Joaquin Miller <[EMAIL PROTECTED]> wrote:
>>> I have changed that text from "needs to" to MUST, although I think that the
>>> sentence before that (The end user's input MUST be normalized into an
>>> Identifier) is pretty unambiguous.
>>  I feel this is an excellent change.  This style should be followed
>> throughout.
>>
>>  The problem with 'needs to' and 'MUST' in the same document is that it
>> leaves the reader this little puzzle to puzzle over:  What is the normative
>> difference between 'needs to' and 'MUST'?  Why is 'needs to' used here and
>> 'MUST' there?  Is 'needs to' weaker than 'MUST'? Is 'needs to' stronger than
>> 'SHOULD'?
> 
> I doubt that the "needs to" wording would have ever caused any
> problems with implementation. The sentence before states that you MUST
> normalize the input. The "needs to" was describing a condition that is
> necessary to check in order to perform the normalization. Anyone who
> was attempting to implement the normalization algorithm would see that
> it is necessary to determine the type of the input before continuing.
> 
> I think that words like MUST and SHOULD are not necessary when
> describing how to do something whose importance has already been made
> clear (by a MUST, etc.). I have a hard time reading prose that uses
> those words excessively, because if they are over-used, they become
> noise ("you already said I MUST normalize").
> 
> Anyway, I think the OpenID 2.0 Authentication specification is pretty
> consistent about using the appropriately strong wording when it's not
> already clear whether something is required, so I think this
> discussion is mostly academic. Feel free to make requests if there are
> specific parts whose compliance is not obvious.
> 
> Josh
-- 
Eve Maler +1 425 947 4522
Technology Director   eve.maler @ sun.com
CTO Business Alliances groupSun Microsystems, Inc.
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: Comments on Auth 2.0 - Pre-Draft 11

[Josh Hoyt]

On 12/11/06, Johannes Ernst <[EMAIL PROTECTED]> wrote:
> >> 14. Discovering OpenID Relying Parties
> >>
> >> Can I ask to append the following sentence?
> >>> The  element is OPTIONAL for this use of the
> >>>  element. If the  element is not given, it
> >>> is assumed to be the URI on which Yadis discovery was performed
> >>> to lead to the XRDS document.
> >>
> >> This would be a useful default that would come very handy. And
> >> right now, the way it is written, this is underdefined in any case.
>
> Resolution?

I made the section explicit on requiring the  element to be
present. [1] This isn't what you asked for, but it avoids the issue of
e.g. what to do if the discovery was performed on an XRI. I hope this
is satisfactory.

Josh

1. 
http://openid.net/svn/listing.php?repname=specifications&path=%2F&rev=213&sc=1
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Off-topic: Re: Comments on Auth 2.0 - Pre-Draft 11

[Gavin Baumanis]

Joaquin / Josh, 

I clearly see the position you both have here.
Overusing verbs can certainly lessen their importance within any
document.
And by the very nature of the work the community is doing and the
people it involved, and the people likely to use the specification - it
is "pretty safe" to say that anyone reading the document is going to
have a level of reading comprehension that should make it irrelevant
which we way go. - I personally haven't wondered whether something was a
MUST have of not - I thought it was always clear enough.

But you never know who will end up reading the document and for what
purpose; and with that in mind, 
I'm going to have to +1, inline with Joaquin's perspective on this
one.

As the new guy - it leaves no doubt in my mind at all as to what MUST
happen.
And if I can get all the MUST HAVES implemented - then surely I SHOULD
have a working implementation of the specification.


Gavin Baumanis
RMIT University, Melbourne, Australia.

>>> On Friday, December 15, 2006 at 08:55, in message
<[EMAIL PROTECTED]>, "Josh
Hoyt"
<[EMAIL PROTECTED]> wrote:
> On 12/14/06, Joaquin Miller <[EMAIL PROTECTED]> wrote:
>>> I have changed that text from "needs to" to MUST, although I think
that the
>>> sentence before that (The end user's input MUST be normalized into
an
>>> Identifier) is pretty unambiguous.
>>
>>  I feel this is an excellent change.  This style should be followed
>> throughout.
>>
>>  The problem with 'needs to' and 'MUST' in the same document is that
it
>> leaves the reader this little puzzle to puzzle over:  What is the
normative
>> difference between 'needs to' and 'MUST'?  Why is 'needs to' used
here and
>> 'MUST' there?  Is 'needs to' weaker than 'MUST'? Is 'needs to'
stronger than
>> 'SHOULD'?
> 
> I doubt that the "needs to" wording would have ever caused any
> problems with implementation. The sentence before states that you
MUST
> normalize the input. The "needs to" was describing a condition that
is
> necessary to check in order to perform the normalization. Anyone who
> was attempting to implement the normalization algorithm would see
that
> it is necessary to determine the type of the input before
continuing.
> 
> I think that words like MUST and SHOULD are not necessary when
> describing how to do something whose importance has already been
made
> clear (by a MUST, etc.). I have a hard time reading prose that uses
> those words excessively, because if they are over-used, they become
> noise ("you already said I MUST normalize").
> 
> Anyway, I think the OpenID 2.0 Authentication specification is
pretty
> consistent about using the appropriately strong wording when it's
not
> already clear whether something is required, so I think this
> discussion is mostly academic. Feel free to make requests if there
are
> specific parts whose compliance is not obvious.
> 
> Josh
> ___
> 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: Comments on Auth 2.0 - Pre-Draft 11

[Josh Hoyt]

Oops, forgot to copy the list...

On 12/14/06, Josh Hoyt <[EMAIL PROTECTED]> wrote:
> On 12/11/06, Johannes Ernst <[EMAIL PROTECTED]> wrote:
> > >> 9.1. Request Parameters
> ...
> > >>> Note: If an OP-SPecific Identifier is not supplied, the
> > >>> Claimed Identifier is considered to have the same as the OP-
> > >>> Specific Identifier. If neither value is present, the assertion
> > >>> is not about an identifier, and will contain other information in
> > >>> its payload, using extensions (Extensions).
> > >
> > > This doesn't seem right; I read your text like this:
> > >
> > >> "If an OP-Specific Identifier is not supplied"
> > > and therefore openid.identity = "http://openid.net/
> > > identifier_select/2.0"
> > >> "the Claimed Identifier is considered to have the same as the OP-
> > >> Specific Identifier."
> > > openid.claimed_id = "http://openid.net/identifier_select/2.0";
> > >
> > > Which is fine, but doesn't cover the remaining cases, i.e. when
> > > Claimed Identifiers / OP-Specific Identifiers *are* supplied.
> > >
> > > The original / current wording does cover these cases, albeit I
> > > admit it is not very easy to read.
> >
> > So I modify my request to modify the wording in a way that it is
> > easier to read.
>
> Attempted.
>
> See 
> http://openid.net/svn/listing.php?repname=specifications&path=%2F&rev=201&sc=1
> and 
> http://openid.net/svn/listing.php?repname=specifications&path=%2F&rev=209&sc=1
>
> Josh
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: Comments on Auth 2.0 - Pre-Draft 11

[Josh Hoyt]

On 12/11/06, Johannes Ernst <[EMAIL PROTECTED]> wrote:
> >> 7.1 Initiation
> >>
> >> Given recent discussions on logo and User Experience, this needs
> >> to be different. Instead of:
> >>
> >>>  To initiate OpenID Authentication, the Relying Party SHOULD
> >>> present the end user with a form that has a field for entering an
> >>> Identifier.
> >>>
> >>> It is RECOMMENDED that a Relying Party place the OpenID logo at
> >>> the beginning of the form field where the end user enters their
> >>> Identifier. This aides in end user recognition that they can use
> >>> an OpenID enabled Identifier at the Relying Party.
> >>
> >> Better:
> >>
> >>> This document does not define a user experience. It is
> >>> RECOMMENDED that implementors follow the OpenID user experience
> >>> if and when such an OpenID user experience has been defined in a
> >>> separate document.
>
> Proposed resolution?

I've taken out the logo recommendation and left it with an input field
in a form with the appropriate "name" attribute. The user-experience
document won't contradict *that* much, and it's a technical necessity
(for e.g. smart software agents to detect the login field).

See 
http://openid.net/svn/listing.php?repname=specifications&path=%2F&rev=212&sc=1

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

Re: Consistency of negative responses to checkid_immediate requests

[Josh Hoyt]

On 12/14/06, Johnny Bufu <[EMAIL PROTECTED]> wrote:
> On 14-Dec-06, at 12:13 AM, Josh Hoyt wrote:
> > On 12/13/06, Martin Atkins <[EMAIL PROTECTED]> wrote:
> >> Josh Hoyt wrote:
> >>>
> >>> It's confusing to me make the failure response to an immediate mode
> >>> request be "id_res", especially if that is not the failure response
> >>> for setup mode. I can't see a reason that they can't both use the
> >>> "cancel" response to indicate that the OP or end user do not wish to
> >>> complete the transaction.
> >>>
> >>> This is a very minor change, but it will make the spec simpler.
> >>>
> >>
> >> I think the RP will want to do something different in these two
> >> cases.
> >
> > That's true, but the RP will probably need to handle the success case
> > differently for immediate mode anyway (e.g. it will have to do AJAX to
> > update the page) so I expect it to have a specific return_to URL for
> > immediate requests. Since using a different return_to is trivial, I
> > prefer the consistency of negative responses.
>
> The current / v1 modes will need to be mentioned in the compatibility
> section, and also implemented. Not sure if this simplification will
> then still be worth.

That's a good point. I guess it comes down to how long OpenID 1.1
support will be necessary. If it's a long time (effectively forever)
then it's definitely not worth it. If it's a relatively short period
of time, then I think it is worth it for the cleaner spec.

Unless someone agrees that it'd be worth it, I'll leave it alone.

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

Off-topic: Re: Comments on Auth 2.0 - Pre-Draft 11

[Josh Hoyt]

On 12/14/06, Joaquin Miller <[EMAIL PROTECTED]> wrote:
>> I have changed that text from "needs to" to MUST, although I think that the
>> sentence before that (The end user's input MUST be normalized into an
>> Identifier) is pretty unambiguous.
>
>  I feel this is an excellent change.  This style should be followed
> throughout.
>
>  The problem with 'needs to' and 'MUST' in the same document is that it
> leaves the reader this little puzzle to puzzle over:  What is the normative
> difference between 'needs to' and 'MUST'?  Why is 'needs to' used here and
> 'MUST' there?  Is 'needs to' weaker than 'MUST'? Is 'needs to' stronger than
> 'SHOULD'?

I doubt that the "needs to" wording would have ever caused any
problems with implementation. The sentence before states that you MUST
normalize the input. The "needs to" was describing a condition that is
necessary to check in order to perform the normalization. Anyone who
was attempting to implement the normalization algorithm would see that
it is necessary to determine the type of the input before continuing.

I think that words like MUST and SHOULD are not necessary when
describing how to do something whose importance has already been made
clear (by a MUST, etc.). I have a hard time reading prose that uses
those words excessively, because if they are over-used, they become
noise ("you already said I MUST normalize").

Anyway, I think the OpenID 2.0 Authentication specification is pretty
consistent about using the appropriately strong wording when it's not
already clear whether something is required, so I think this
discussion is mostly academic. Feel free to make requests if there are
specific parts whose compliance is not obvious.

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

Re: [OpenID] OpenID IPR Policy Draft

[Aldo Castañeda]

List members,

With permission from Lawrence Rosen , I'm
copying some of his comments that
he posted to the IETF's IPR Working Group mailing list in the last few days.
I'm
doing so for two reasons:

1. As everybody considers what approach is best with regard to IPR, I think
Mr.
Rosen's views (as far as I'm concerned he has a sterling reputation among
"open"
advocates") are at a minimum worthy of consideration.

2. I've asked Larry to participate in a podcast on this subject and although
he and
I haven't worked out all the details yet he has agreed to participate and
I'd like to
know if anyone on this list might like to participate in the podcast "live"
or submit
questions for me to ask him?

/Start Lawrence Rosen's Comments to IETF-IPR-WG

Far more important is the goal that IETF specifications, even the
"examples," can be implemented with equal rights and conditions in both
proprietary and open source software and documentation.

As you know, I'm a strong supporter of open source. But when it comes to
*open standards*, I believe we have a broader responsibility to be free for
all--without a share-alike license that disadvantages proprietary software.

That is why, for a patent covenant, I support the Microsoft Open
Specification Promise as the clearest expression yet of this principle. IETF
should demand similar covenants today from other patent-owning companies for

free implementation of patented technology in IETF industry standards--in
both open source and proprietary software.

And that is also why, for a copyright grant, I recommend a license such as
AFL 3.0, which grants a license to everyone (for both text and code!)
conditioned only upon fair attribution and the retention of defensive rights
in the event of patent or copyright litigation.

Of course, when someone implements an IETF specification, he or she can
*then* choose to distribute that implementation under a share-alike license.

I'll cheer that decision! I may even recommend, as do Linux standards
organizations and other open source projects, that the GPL-licensed software
become a model implementation against which others are judged. :-) But
that's very different from contaminating IETF specifications with code or
text that some companies can't or won't be able to use.

/End Lawrence Rosen's Comments to IETF-IPR-WG



On 12/8/06, Ben Laurie <[EMAIL PROTECTED]> wrote:


On 12/7/06, Gabe Wachob <[EMAIL PROTECTED]> wrote:
> Ben-
> I'm not sure what you are suggesting is the problem - is this
just a
> matter of timing? That is, could we remedy your issue by saying that you

> have to issue the license before a certain event? This language is
pretty
> common - I'm not sure what else a policy could say?
>
> Are you suggesting that there is some sort of implied license or

> estoppel that comes into creation by virtue of the policy? I'm not aware
of
> any IPR policy in standards bodies that works that way - and I'm not
sure
> its really effective from a legal point of view.
>
> As an alternative, when we say "issue a license", perhaps we
should
> be saying "a unilateral license or covenant of non-assertion (etc) that
does
> not require affirmative action on the part of the licensee" (needs to be

> worded right - but does that capture your intent?)

Yes, that's what I'm after.

> I'd note that the w3c and
> oasis (rf on limited terms) policies do *not* require patent licensors
to
> issue these sort of super-low-friction licenses (though I've personally
> pushed for it within OASIS).

I know, and it can be a problem.

>
> -Gabe
>
> > -Original Message-
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On
> > Behalf Of Ben Laurie
> > Sent: Thursday, December 07, 2006 8:31 AM
> > To: Recordon, David
> > Cc: specs@openid.net; [EMAIL PROTECTED]
> > Subject: Re: [OpenID] OpenID IPR Policy Draft
> >
> > On 12/6/06, Recordon, David < [EMAIL PROTECTED]> wrote:
> > > Hey guys,
> > > Been working with Gabe, and others, on starting to draft an IPR
Policy
> > > for OpenID specifications.  We'd appreciate feedback in terms of if
what
> > > is written captures the correct intent of the community?  We realize
the
> > > language isn't technically as tight as it needs to be, though first
want
> > > to make sure it is saying the right thing.  It is largely based on
the
> > > IPR Policy for Microformats.
> > >
> > > http://openid.net/wiki/index.php/IPR_Policy
> >
> > A problem with saying "you MUST offer ... a royalty free license" is
> > that in order to be open-source-friendly the licence has to be
> > automatic - otherwise potentially each user of the s/w has to jump
> > through hoops to get the licence.
> >
> > >
> > > Thanks,
> > > --David
> > > ___
> > > general mailing list
> > > [EMAIL PROTECTED]
> > > http://openid.net/mailman/listinfo/general
> > >
> > ___
> > general mailing list
> > [EMA

Re: [OpenID] OpenID IPR Policy Draft

[James A. Donald]

Gabe Wachob wrote:
 > Actually, the language was changed from "post to a
 > list", not "subscribe to a list" for this very reason.

It appears to me that your intent is, or should be, to
protect against patent trolls, who are likely to
retroactively patent the OpenID standard now that it is
being widely adopted.

In the US, you can file a patent in which you *claim*
you invented stuff one year prior to the patent
application.

So the technology is first proposed and described on
this list, on 2006 December 7, 2006.  It is incorporated
into the standard and comes to be widely used around
about, say, 2007 August.  On 2007 December 5, 2007, the
patent troll has a friendly individual inventor file an
patent application claiming to have invented the
technology on 2007, december 6.

They keep the patent under water for a couple of years,
preventing it from being published, until evil unpopular
giant megacorp, say intel, has been using the technology
for some time.  They then surface the patent.  Should
intel fail to settle, they have inventor tell the jury
he is being oppressed by evil giant megacorp.  Jury
awards the patent troll a zillion dollars, and cabillion
on top of that.

Unfortunately, your proposed measure is of limited
effectiveness, since the our friend the highly jury
sympathetic inventor is probably not signed up on this
list, his expertise being primarily in being loved by
juries, rather than computer technology.

Indeed, no measures whatsoever are likely to be very
effective.  The patent office wants people to take out
more patents, just as Ford wants people to buy more
Fords.  The judiciary similarly wants more human
activity to be subject to patents, just as they want
more laws, and those laws of broader scope, hence the
steady shrinkage of any portion of the constitution that
begins "congress shall make no law ..."
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: [OpenID] OpenID IPR Policy Draft

[Ben Laurie]

On 12/7/06, Gabe Wachob <[EMAIL PROTECTED]> wrote:
> Ben-
> I'm not sure what you are suggesting is the problem - is this just a
> matter of timing? That is, could we remedy your issue by saying that you
> have to issue the license before a certain event? This language is pretty
> common - I'm not sure what else a policy could say?
>
> Are you suggesting that there is some sort of implied license or
> estoppel that comes into creation by virtue of the policy? I'm not aware of
> any IPR policy in standards bodies that works that way - and I'm not sure
> its really effective from a legal point of view.
>
> As an alternative, when we say "issue a license", perhaps we should
> be saying "a unilateral license or covenant of non-assertion (etc) that does
> not require affirmative action on the part of the licensee" (needs to be
> worded right - but does that capture your intent?)

Yes, that's what I'm after.

> I'd note that the w3c and
> oasis (rf on limited terms) policies do *not* require patent licensors to
> issue these sort of super-low-friction licenses (though I've personally
> pushed for it within OASIS).

I know, and it can be a problem.

>
> -Gabe
>
> > -Original Message-
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> > Behalf Of Ben Laurie
> > Sent: Thursday, December 07, 2006 8:31 AM
> > To: Recordon, David
> > Cc: specs@openid.net; [EMAIL PROTECTED]
> > Subject: Re: [OpenID] OpenID IPR Policy Draft
> >
> > On 12/6/06, Recordon, David <[EMAIL PROTECTED]> wrote:
> > > Hey guys,
> > > Been working with Gabe, and others, on starting to draft an IPR Policy
> > > for OpenID specifications.  We'd appreciate feedback in terms of if what
> > > is written captures the correct intent of the community?  We realize the
> > > language isn't technically as tight as it needs to be, though first want
> > > to make sure it is saying the right thing.  It is largely based on the
> > > IPR Policy for Microformats.
> > >
> > > http://openid.net/wiki/index.php/IPR_Policy
> >
> > A problem with saying "you MUST offer ... a royalty free license" is
> > that in order to be open-source-friendly the licence has to be
> > automatic - otherwise potentially each user of the s/w has to jump
> > through hoops to get the licence.
> >
> > >
> > > Thanks,
> > > --David
> > > ___
> > > general mailing list
> > > [EMAIL PROTECTED]
> > > http://openid.net/mailman/listinfo/general
> > >
> > ___
> > general mailing list
> > [EMAIL PROTECTED]
> > http://openid.net/mailman/listinfo/general
>
>
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: Comments on Auth 2.0 - Pre-Draft 11

[Joaquin Miller]

I have changed that text from "needs to" to MUST, although I think 
that the sentence before that (The end user's input MUST be 
normalized into an Identifier) is pretty unambiguous.


I feel this is an excellent change.  This style should be followed throughout.

The problem with 'needs to' and 'MUST' in the same document is that 
it leaves the reader this little puzzle to puzzle over:  What is the 
normative difference between 'needs to' and 'MUST'?  Why is 'needs 
to' used here and 'MUST' there?  Is 'needs to' weaker than 'MUST'? Is 
'needs to' stronger than 'SHOULD'?


Cordially, Joaquin


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

Re: Comments on Auth 2.0 - Pre-Draft 11

[Josh Hoyt]

On 12/14/06, Johannes Ernst <[EMAIL PROTECTED]> wrote:
> So you believe that it is tight enough that if you and I implement
> the spec, and somebody types the exact same character string into
> both of our implementations, it will produce the exact same result,
> regardless what the character string was?

Yes, that's what I think. :)

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

Re: Comments on Auth 2.0 - Pre-Draft 11

[Josh Hoyt]

(I will be addressing the remaining issues that you brought up one at a time)

On 12/11/06, Johannes Ernst <[EMAIL PROTECTED]> wrote:
> >> 7.2 Normalization
> >>
> >> I'm not sure that this -- all of which is OPTIONAL -- should be in
> >> this document. I would suggest to either make it MANDATORY -- or
> >> to take it out of this document and refer to a User Experience
> >> document instead.
> >>
> >> The problem is that if the user can type in something incomplete
> >> at site A, and then types in the same incomplete thing at site B,
> >> it may work at A but differently at B, which is no good. So either
> >> make these rules MANDATORY, or delegate them into the user
> >> experience.
> >
> > Normalization is not optional at all - not sure why you understood
> > it was. Maybe that section needs to be clarified, if you can point
> > it to us.
>
> I am referring to par 1 sentence 2, where is says "needs to" instead
> of "MUST ... according to the following algorithm".
> Then to the entire paragraph 2, which says SHOULD.
>
> I'd like an algorithm that produces the same normalized identifier
> from the same entered text string, regardless of site.

I have changed that text from "needs to" to MUST, although I think
that the sentence before that (The end user's input MUST be normalized
into an Identifier) is pretty unambiguous.

Paragraph two about normalizing XRIs I think was David's text, so I
guess I'll wait for his response about that. I think he's on vacation.

Other than the SHOULD for recognizing XRI global context symbols and
adding the xri:// prefix, I think that the normalization section is
pretty tight and will not lead to inconsistencies in implementation.

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

Re: Consistency of negative responses to checkid_immediate requests

[Johnny Bufu]

On 14-Dec-06, at 12:13 AM, Josh Hoyt wrote:

> On 12/13/06, Martin Atkins <[EMAIL PROTECTED]> wrote:
>> Josh Hoyt wrote:
>>>
>>> It's confusing to me make the failure response to an immediate mode
>>> request be "id_res", especially if that is not the failure response
>>> for setup mode. I can't see a reason that they can't both use the
>>> "cancel" response to indicate that the OP or end user do not wish to
>>> complete the transaction.
>>>
>>> This is a very minor change, but it will make the spec simpler.
>>>
>>
>> I think the RP will want to do something different in these two  
>> cases.
>
> That's true, but the RP will probably need to handle the success case
> differently for immediate mode anyway (e.g. it will have to do AJAX to
> update the page) so I expect it to have a specific return_to URL for
> immediate requests. Since using a different return_to is trivial, I
> prefer the consistency of negative responses.

The current / v1 modes will need to be mentioned in the compatibility  
section, and also implemented. Not sure if this simplification will  
then still be worth.

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

Re: Consistency of negative responses to checkid_immediate requests

[Josh Hoyt]

On 12/13/06, Martin Atkins <[EMAIL PROTECTED]> wrote:
> Josh Hoyt wrote:
> >
> > It's confusing to me make the failure response to an immediate mode
> > request be "id_res", especially if that is not the failure response
> > for setup mode. I can't see a reason that they can't both use the
> > "cancel" response to indicate that the OP or end user do not wish to
> > complete the transaction.
> >
> > This is a very minor change, but it will make the spec simpler.
> >
>
> I think the RP will want to do something different in these two cases.

That's true, but the RP will probably need to handle the success case
differently for immediate mode anyway (e.g. it will have to do AJAX to
update the page) so I expect it to have a specific return_to URL for
immediate requests. Since using a different return_to is trivial, I
prefer the consistency of negative responses.

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