RE: OpenID Email Discovery

[Gabe Wachob]

I'm sorry, Phillip, we're not going to let you get away with that one. 

 

Drummond already asked you about what you are talking about w/r/t IPR
commitments, and I haven't seen a reply. All IPR commitments for XRI are in
place and have been for quite a while. I encourage you to review the "RF on
Limited Terms" option (under which the TC operates) of
http://www.oasis-open.org/who/intellectualproperty.php 

 

I appreciate your technical discussion, but please don't drop the IPR FUD
bomb without substantiation or explanation. Thanks.

 

-Gabe

 

  _  

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Hallam-Baker, Phillip
Sent: Thursday, January 03, 2008 3:03 PM
To: Peter Davis
Cc: OpenID specs list
Subject: Re: OpenID Email Discovery

 

NAPTR is an ietf proposed standard but there is no deployed base. SRV has
been supported in windows since 2000 and bind since before then.

XRI is a specification, not an OASIS recommendation. Until the IPR
commitments necessary to allow that change are made there is no standard.


Sent from my GoodLink Wireless Handheld (www.good.com)

 -Original Message-
From:   Peter Davis [mailto:[EMAIL PROTECTED]
Sent:   Thursday, January 03, 2008 02:07 PM Pacific Standard Time
To: Hallam-Baker, Phillip
Cc: Eran Hammer-Lahav; OpenID specs list
Subject:Re: OpenID Email Discovery

actually, NAPTR RR's would be a better fit, as the unique-part of an 
openID may be in the local-path part of a URI, not the hostname... of 
course, if a users openID changes, so too might their underlying DNS 
name, and then DNS won't help you at all there.  XRI is better 
situated to solve that use case.

=peterd

On Jan 3, 2008, at 4:48 PM, Hallam-Baker, Phillip wrote:

> This is the function of the existing DNS SRV record.
>
> _openid.example.com  SRV 1 1 1 1 openid1.example.com
>
> The Internet has an architecture already. Use it, don't try to 
> reinvent it.
>
> From: [EMAIL PROTECTED] on behalf of Eran Hammer-Lahav
> Sent: Thu 03/01/2008 4:01 PM
> To: 'OpenID specs list'
> Subject: OpenID Email Discovery
>
> (The full story is posted at http://www.hueniverse.com/hueniverse/
> 2008/01/addressing-open.html but this contains the technical parts 
> of the post).
>
>
> This proposal adds Email Discovery allowing users to use their 
> email address as an OpenID.
>
>
> .
>
>
> We need to map between the email to the OpenID identifier and this 
> is where DNS comes in. DNS already has a system for resolving email 
> addresses into an actual server - email resolution using an MX 
> record. Why not add a new record type for OpenID. Basically another 
> way to perform OpenID discovery that is all about making it user-
> friendly.
>
>
> All that is needed is a URL the site performing discovery can 
> append the email to and treat it as an OpenID identifier. This can 
> be done using a OpenID TXT record: 'OpenID [username rule] 
> [priority] [URL]' where [username rule] is a wildcard expression 
> used to match the username part of the email (everything up to the 
> '@'), [priority] is the MX-like priority value, and [URL] is the 
> URL used to generate the OpenID identifier. The URL uses '*' to 
> indicate where the username is inserted, and '**' to indicate where 
> the full, URL-encoded, email address is inserted (both optional). 
> For example:
>
>
> example.com   TXT   'OpenID * 10 http://*.example.com/'
>
> example.com   TXT   'OpenID joe 10 http://example.org/openid?**'
>
>
> Which reads: for any email address '@example.com' other than 'joe' 
> use 'http://username.example.com/' as the OpenID identifier. For 
> email address '[EMAIL PROTECTED]' use 'http://example.org/openid?joe%
 
> 40example.com' as the OpenID identifier. Rules are processed first 
> based on the username rule match (in order of match closeness) and 
> then on priority which is used in the same manner as MX records 
> priority.
>
>
> .
>
>
> There are many ways to implement identity delegation, but in the 
> context of email identifiers and simplifying the user experience, 
> the idea is to move the delegation mapping to the OpenID provider. 
> When users sign-up for a new OpenID, they will be given the option, 
> perhaps as a premium paid service, to make the OpenID provider map 
> incoming identity checks for the user email address with their 
> local OpenID identifier. So instead of the users telling the site 
> about their local identity (using delegation), the OpenID provider 
> will perform the mapping.
>
>
> In the above example, '[EMAIL PROTECTED]' has his OpenID managed by 
> 'example.org'. When signing up for an OpenID at 'example.org', Joe 
> asked it to accept identity requests for '[EMAIL PROTECTED]' or at 
> least provide delegation discovery. When Joe tries to log into an 
> OpenID-enabled site using '[EMAIL PROTECTED]', the site convert the 
> email address to the URL 'http://example.org/openid?joe%
 
> 40examp

RE: OpenID 2.0 finalization progress

[Gabe Wachob]

I think that's exactly right, though it's really easy to have blind spots
when it comes to figuring out the permutations of how one can game group
behavior... so I won't guarantee anything else could happen (I've learned
that much from law school ;)

As I said, I *believe* the all the actors involved wish to work in the
community's best interest - though my belief in the goodness of humanity
doesn't really carry any legal meaning!!!

-Gabe

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Josh
> Hoyt
> Sent: Monday, October 22, 2007 3:29 PM
> To: Gabe Wachob
> Cc: Kevin Turner; specs
> Subject: Re: OpenID 2.0 finalization progress
> 
> On 10/22/07, Gabe Wachob <[EMAIL PROTECTED]> wrote:
> > 3) the community calls the spec final and a contributor raises a
> potential
> > patent infringement issue, and since the community has already
> implemented
> > and deployed 2.0, the patent owner has more leverage because the costs
> of
> > "engineering around" the claims in the patent have gone way up because
> of
> > already-deployed software.
> 
> In order for this to be a concern, there needs to be a party who
> currently:
>  1. has a patent that the spec infringes upon
>  -- and --
>  2. intends to claim infringement it if the spec is released without
> an IPR agreement in place
>  -- and --
>  3. would be party to the IPR agreement
> 
> Did I get this right?
> 
> Josh

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

RE: OpenID 2.0 finalization progress

[Gabe Wachob]

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
> Of Kevin Turner
> Sent: Monday, October 22, 2007 1:34 PM
> To: specs
> Subject: Re: OpenID 2.0 finalization progress
> 
> On Fri, 2007-10-19 at 16:12 -0700, Johannes Ernst wrote:
> > [...] and after they had produced a spec, Rambus said "but we have
> > some patents". This lead to at least one lawsuit I believe.
> >
> > I have heard wildly diverging assessments on whether or not this
> > could happen here.
> 
> Ok, I'm looking for the devil's advocate here, so let's assume the
> worst.  Say we call the spec final now, and then sometime in the next
> forty days, a problem like that comes up.  What are the consequences of
> that?  Specifically, do any of the solutions to that hypothetical
> problem involve changing the spec?  In what way?

Typically, the community would choose to remove or change the part of the
spec which ostensibly infringed upon claims raised by a patentholder. This
could be major or it could be minor. Can't tell until someone raises a
patent claim. 

> The way I understand it, right now one of two things happens:
> 
> 1) Things go more-or-less smoothly now.  The IPR policy may get tinkered
> with a little bit during the review period but this does not influence
> the technical specification.
> 
> 2) The sky falls and we decide that there is no IPR policy that can
> possibly cover the current specification, so we must change the
> specification.  Given our track record at publishing new drafts, this
> means that we wouldn't be final until _at least_ Q1 2008, if not Q2.

The third possibility is the real concern (that Johannes is referring to):

3) the community calls the spec final and a contributor raises a potential
patent infringement issue, and since the community has already implemented
and deployed 2.0, the patent owner has more leverage because the costs of
"engineering around" the claims in the patent have gone way up because of
already-deployed software. 

I'm not saying #3 is likely - but that's the scenario we are trying to
prevent. 

-Gabe


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

RE: OpenID 2.0 finalization progress

[Gabe Wachob]

Dick is right here regarding the certainty that an IPR policy provides with
respect to patent. 

And IPR policy can never ensure that everyone in the world will refrain from
making patent claims. With regards to patent, an IPR policy and procedure
can only really affect those who choose to be subject to it, either
passively by participating in a standards process, or actively by issuing a
license or non-assert. 

So Dick is right that it's not 100% protection - but it does at least
demonstrate that those directly involved are not attempting to induce
implementations which are covered by patent claims for which patent holders
intend to demand royalties or impose other unacceptable restrictions on use.

  -Gabe

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
> Of Dick Hardt
> Sent: Monday, October 22, 2007 2:44 AM
> To: [EMAIL PROTECTED]
> Cc: specs@openid.net
> Subject: Re: OpenID 2.0 finalization progress
> 
> 
> On 19-Oct-07, at 10:20 PM, David Recordon wrote:
> 
> > Completely agreed with Johannes.  We are very close with the IPR
> > policy/process being in place and assuming all the contributors agree
> > to it, 2.0 can be declared final within 30 days of October 30th as
> > that is the end of the public review period for the policy.  2.0 is
> > really important and has a wide range of contributors, we've all put
> > a lot of effort into this, lets make sure we do this right.
> 
> Doing it right would have been to have had a process in place over a
> year ago. A little late to be doing it right now. Now we are having
> to clean up the mess!
> 
> >
> > To Kevin's question, the IPR policy does not require a patent search,
> > which as he points out could be a lengthy process.  Rather it
> > requires that all contributors to the specification make a non-
> > assertion statement to ensure that the spec truly is free and not
> > encumbered by any patents.
> 
> Just because the contributors all make non-assertion statements does
> not make the spec unencumbered. Non-contributors could have patents
> that are asserted.
> 
> While having an IPR policy in place will, provide more certainty
> around the IPR, it will NOT ensure the spec is free.
> 
> 
> > I spoke with Brad Fitzpatrick (cc'd)
> > tonight about this and he too agrees that 2.0 should not be declared
> > final until it has gone through the IPR review cycle to fully ensure
> > that it is clear from any IPR encumbrances in regards to the
> > contributors.
> 
> You forgot to not cc Brad, and I'd prefer to hear from Brad himself
> then have you channel him.
> 
> -- Dick
> ___
> 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 2.0 finalization progress

[Gabe Wachob]

I've already suggested that to the OAuth community and they are heartily
taking up that suggestion... 

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
> Of Pat Patterson
> Sent: Friday, October 19, 2007 4:36 PM
> To: Johannes Ernst
> Cc: specs@openid.net
> Subject: Re: OpenID 2.0 finalization progress
> 
> +1 FWIW
> 
> Interested parties, feel free to use the Sun OpenID NAC as a model -
> http://www.sun.com/software/standards/persistent/openid/nac.xml
> 
> Cheers,
> 
> Pat
> 
> On Oct 19, 2007, at 4:12 PM, Johannes Ernst wrote:
> 
> > Some years ago, if I recall correctly, Rambus participated in an open
> > industry process (or so the other participants thought) to define
> > certain memory communications protocols, and after they had produced
> > a spec, Rambus said "but we have some patents". This lead to at least
> > one lawsuit I believe.
> >
> > I have heard wildly diverging assessments on whether or not this
> > could happen here. The way to move forward is to put the IPR policy
> > in place prior to declaring any new specs final; fortunately we are
> > very close on the IPR policy.
> >
> > I strongly suggest that whoever feels the urgency to get a 2.0 spec
> > declared final to help out driving the IPR process to a close. That's
> > on the critical path, and that's where all energies should be
> > directed.
> >
> > On Oct 19, 2007, at 12:23, Kevin Turner wrote:
> >
> >> On Fri, 2007-10-19 at 10:02 -0700, Paul C. Bryan wrote:
> >>> On Thu, 2007-10-18 at 19:13 -0700, Dick Hardt wrote:
> >>>
>  I don't see why the two processes need to be any more dependant on
>  each other then they are already.
> >>>
> >>> With all due respect, why take the risk that there are intellectual
> >>> property issues after the specification is finalized?
> >>
> >> I'll let my ignorance show here: How will any potential IPR issues
> >> affect the final specification?  I recognize that many parties
> >> require
> >> the IPR documentation before moving forward with their adoption of
> >> OpenID.  However, there are many parties who do _not_ feel that need,
> >> and I do not understand what the downside is to calling the
> >> specification final now.  Are we waiting on the results of a patent
> >> search which might necessitate re-working parts of the protocol?
> >> What
> >> exactly are the consequences, worst case, in calling the
> >> specification
> >> "final" before the IPR is sealed?
> >>
> >>
> >>
> >> ___
> >> specs mailing list
> >> specs@openid.net
> >> http://openid.net/mailman/listinfo/specs
> >
> > ___
> > specs mailing list
> > specs@openid.net
> > http://openid.net/mailman/listinfo/specs
> 
> - - - - -
> Pat Patterson
> Federation Architect, Sun Microsystems, Inc.
> [EMAIL PROTECTED] - http://blogs.sun.com/superpat
> - - - - -
> Join OpenSSO today! http://opensso.dev.java.net/
> - - - - -
> 
> 
> 
> 
> ___
> 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: Using dots in HTTP request parameters

[Gabe Wachob]

Not sure it matters in the O* environments, but using _ in http links has
traditionally been frowned upon because it when rendered as underlined text
(as an HTML link), the underscores disappeared and made it look like a space
was present in the link. 


-Gabe

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
> Of Jonathan Daugherty
> Sent: Friday, September 14, 2007 11:05 AM
> To: Eran Hammer-Lahav
> Cc: specs@openid.net
> Subject: Re: Using dots in HTTP request parameters
> 
> # OAuth is designed to work with old browsers, cell phones, webtv,
> # etc. Is there any reason not to use dot in parameters name? Are
> # there any known compatibility or support issues (compared to using
> # underscores)?
> 
> PHP has an especially pathological behavior of converting all dots in
> query parameter names to underscores, so if you do go this route
> you'll need code[1] to fix it.  Otherwise I think it's a fine idea. :)
> 
> [1] Auth_OpenID::getQuery()
> http://openidenabled.com/files/php-openid/repos/2.x.x/Auth/OpenID.php
> 
> --
>   Jonathan Daugherty
>   JanRain, Inc.
>   irc.freenode.net: cygnus in #openid
>   cygnus.myopenid.com
> ___
> 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: RFC: Final outstanding issues with the OpenID 2.0Authenticationspecification

[Gabe Wachob]

BTW, we (the XRI TC cochairs) finally (!) came to agreement at IIW to
publish the current draft of the XRI Res spec as a citeable committee spec
so the issue about XRI specs being in draft form and unciteable goes away.
That is, we'll hold a TC vote on what has already been implemented by the
openid community and call it XRI resolution 2.0 (which has been relatively
stable, but not final, for a long time already). XRI Syntax 2.0 has been a
committee spec for a long time now and has not changed. The agreement was,
essentially, to output res 2.0 wd 11 (or thereabouts) as a committee spec
rather than wait for further work on XRI.  

We've not formally presented this to the TC, but I am almost certain the TC
will agree to this. 

It is my expectation that we'll complete this in roughly the same timeframe
as the other work being completed in OpenID 2.0 (that is, on the order of
weeks). 

-Gabe

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
> Of Josh Hoyt
> Sent: Thursday, May 17, 2007 1:40 PM
> To: Dmitry Shechtman
> Cc: OpenID specs list
> Subject: Re: RFC: Final outstanding issues with the OpenID
> 2.0Authenticationspecification
> 
> On 5/17/07, Dmitry Shechtman <[EMAIL PROTECTED]> wrote:
> > "aside from XRI and Yadis"? XRI alone is twice as complex as OpenID 1.1!
> >
> > There has been a simplification suggestion floating around since long
> ago:
> > resolve i-names via http[s]://xri.net/.
> 
> -1. If XRI is to be included, it should be done the way that it's
> intended. One possible solution that would address this problem as
> well as the unfinished XRI specification is to split out Yadis and XRI
> discovery out from the OpenID Authentication spec and into separate
> documents. That way, they could wait until the XRI specs are done and
> the OpenID spec will be shorter and easier to understand.
> 
> 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: axschema.org instead of openid.net

[Gabe Wachob]

+1 

Thanks for taking the initiative. 

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
> Of Dick Hardt
> Sent: Friday, April 20, 2007 12:46 PM
> To: OpenID specs list
> Subject: axschema.org instead of openid.net
> 
> Thanks everyone for feedback on using schema.openid.net. Here are my
> conclusions:
> 
> 1) A number of people would like to be using a web oriented schema
> right away and don't want to wait for other groups to create the schema.
> 
> 2) A number of people are allergic to the openid.net domain being
> used for things that are not openid.net protocol specific.
> 
> Sxip has acquired axschema.org (Attribute eXchange schema :-) and we
> will host the site and a mail list as a service to the community and
> operate it per http://openid.net/specs/openid-attribute-
> types-1_0-02.html
> 
> If I don't hear from anyone that they don't like this idea, then we
> will set this up next week.
> 
> -- Dick
> ___
> 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: Java RP

[Gabe Wachob]

Hans-
I didn't see XRI support in joid - was I mistaken? 

-Gabe

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
> Of Granqvist, Hans
> Sent: Wednesday, April 11, 2007 9:31 AM
> To: Dick Hardt; McGovern, James F ((HTSC, IT))
> Cc: specs@openid.net
> Subject: RE: Java RP
> 
> Or this library (also ASF 2.0) for creating both OP and RP,
> which follows a slightly different API approach:
> 
>  http://code.google.com/p/joid
> 
> (If you're coming to JavaOne in May, there will be a
> presentation on it.)
> 
> -Hans
> 
> 
> > -Original Message-
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] On Behalf Of Dick Hardt
> > Sent: Wednesday, April 11, 2007 9:15 AM
> > To: McGovern, James F ((HTSC, IT))
> > Cc: specs@openid.net
> > Subject: Re: Java RP
> >
> > The OpenID4Java library is licensed under Apache 2.0 -- a
> > very commercial friendly license
> >
> > source development here:
> > http://code.google.com/p/openid4java/source
> >
> > package here:
> > http://code.sxip.com/openid4java/
> >
> > -- Dick
> >
> > On 11-Apr-07, at 6:37 AM, McGovern, James F ((HTSC, IT)) wrote:
> >
> > > I have been thinking that the best contribution I could
> > make to OpenID
> > > would be the first enterprise that deploys OpenID into production.
> > > OpenID needs more press than it is receiving and by showing that a
> > > large Fortune enterprise is using would be a big win. I do however
> > > have one constraint in that the absolute fastest way of
> > accomplishing
> > > deployment would be for me to identify a 100% unrestricted
> > open source
> > > Java RP code base that I could incorporate.
> > >
> > > The notion of going through any form of procurement would
> > not allow me
> > > to accomplish this goal. Is anyone aware of the existence of a 100%
> > > unrestricted open source Java RP code base?
> > >
> > >
> > >
> > **
> > 
> > > ***
> > > This communication, including attachments, is
> > > for the exclusive use of addressee and may contain proprietary,
> > > confidential and/or privileged information.  If you are not the
> > > intended
> > > recipient, any use, copying, disclosure, dissemination or
> > > distribution is
> > > strictly prohibited.  If you are not the intended
> > recipient, please
> > > notify
> > > the sender immediately by return e-mail, delete this
> > communication and
> > > destroy all copies.
> > >
> > **
> > 
> > > ***
> > >
> > > ___
> > > 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

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

RE: Web Access Management

[Gabe Wachob]

Is that really true Mart? 

Isn't it at least as much the perception that OpenID isn't usable by
organizations acting as RP's that cannot manage the risk associated with
accepting an authentication assertion from OP "out there"?  That is, the
perception is that OpenID is good for Jyte and blog comments, but not for
anything serious or of value (on the RP side)? 

This perception is reasonable from some points of view. 

And there's the Phishing concerns... 

I do think the IPR stuff is an issue (of course), but I don't think it's the
main reason there isn't more interest from the big (RP-oriented) players
yet. I think there's been little said to assuage the above concerns because
many of the folks here aren't interested, as a matter of world-view, in the
problems of large RP's who have business risks associated with unknown OP's.


Those risks *can* be addressed and/or mitigated in a number of interesting
ways, but we're still pretty early on in the development of OpenID as a
deployed infrastructure now...  

-Gabe

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
> Of Martin Atkins
> Sent: Thursday, April 05, 2007 4:41 PM
> To: specs@openid.net
> Subject: Re: Web Access Management
> 
> Hans Granqvist wrote:
> >> Ping demoed OpenID technology at RSA.
> >>
> >> I hear Novell and IBM are looking at supporting OpenID.
> >>
> >> Microsoft has said they will in future products.
> >>
> >> Oracle and CA are following OpenID.
> >>
> >> So, yes. :-)
> >>
> >
> > I'm curious why almost all of these companies are non-existent
> > on the mailing lists.  Any insights?
> >
> 
> It seems that at this time the uncertain policies for issues such as
> patents and trademarks surrounding OpenID are putting off larger
> companies from directly participating.
> 
> This is a current hot-topic for the OpenID Foundation, since getting
> such companies fully on board would likely be beneficial.
> 
> 
> ___
> 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: Promoting OpenID

[Gabe Wachob]

More likely that the people promoting OpenID to large organizations are
vendors and don't particularly want to tell their competitors what they are
doing. 

Now, imagine if there were like-minded vendors getting together to form some
sort of marketing organization to promote OpenID to a variety of audiences,
including large enterprises... ;-)

-Gabe

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
> Of Recordon, David
> Sent: Tuesday, April 03, 2007 12:18 PM
> To: McGovern, James F (HTSC, IT); specs@openid.net
> Subject: RE: Promoting OpenID
> 
> People might be, though nothing real formal that I personally know of.
> You volunteering? :P
> 
> --David
> 
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of McGovern, James F (HTSC, IT)
> Sent: Monday, April 02, 2007 8:15 AM
> To: specs@openid.net
> Subject: Promoting OpenID
> 
> As an end-user to user-centric approaches, I have noticed an interesting
> pattern. Microsoft does a wonderful job of selling Cardspace as a
> solution to others who develop in Microsoft languages. Likewise, there
> are tons of vendors that can offer solutions for large enterprises to
> purchase but no one is promoting user-centric approaches to the vendors
> us large enterprises do business with in terms of getting them to
> embrace user-centric approaches within their own code base. Sure, we can
> as consumers raise awareness, but I would like to understand thoughts on
> other than procurement, how could we make this more pervasive?
> 
> Is anyone here working with vendors in the ERP, CRM, ECM, BPM or VRM
> spaces such that user-centric identity is built into their product?
> 
> 
> 
> *
> This communication, including attachments, is for the exclusive use of
> addressee and may contain proprietary, confidential and/or privileged
> information.  If you are not the intended recipient, any use, copying,
> disclosure, dissemination or distribution is strictly prohibited.  If
> you are not the intended recipient, please notify the sender immediately
> by return e-mail, delete this communication and destroy all copies.
> 
> *
> 
> ___
> 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

RE: Features for Future Versions

[Gabe Wachob]

Before we get into the discussions on this list (and hopefully elsewhere),
it would be great if you (and anyone else contributing) could make a clear
IPR statement about your intent with this new functionality. If you wanted
to use Microsoft's Open Specification Promise as a template, that would be
great. We don't have formal policy about IPR moving forward (and how such a
policy would be enforced...), but the more intentions are made clear earlier
on, he better it is for everyone involved. 



David Recordon and I have been pulled in 14 different directions - one of
the things we are tasked with is cleaning up the IPR around OpenID. Such a
task would have been made simpler if everyone had stated up front that their
contributions were not subject to IPR claims (or that if they were, they
would be licensed for use with OpenID, etc). Of course, without a more
formal process and IPR policy in place, such commitments to IPR openness are
not very likely to be given forth ad hoc. So this isn't a criticism, its
just a result of the way things have happened. 

-Gabe

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
> Of Drummond Reed
> Sent: Monday, April 02, 2007 11:26 AM
> To: 'Dick Hardt'; 'McGovern, James F ((HTSC, IT))'
> Cc: specs@openid.net
> Subject: RE: Features for Future Versions
> 
> James,
> 
> I agree with Dick's feedback. I don't believe OpenID, as an overall
> Internet
> identity framework, is subject to either limitation you asked about. But
> we
> must work our way up into each of those areas of functionality.
> 
> The more you can tell us about specific functions and use cases you'd like
> to see supported, the better we can appraise what it will take to get
> there.
> 
> =Drummond
> 
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
> Of Dick Hardt
> Sent: Monday, April 02, 2007 8:20 AM
> To: McGovern, James F ((HTSC, IT))
> Cc: specs@openid.net
> Subject: Re: Features for Future Versions
> 
> 
> On 2-Apr-07, at 8:09 AM, McGovern, James F ((HTSC, IT)) wrote:
> 
> > I originally joined this list with the hopes of injecting support
> > for relationships, authorization and attestation into the
> > specification but have been somewhat disappointed. I do have the
> > following questions?
> >
> > 1. Will OpenID avoid incorporating features where identity
> > selectors such as Cardspace don't support the functionality?
> >
> > 2. Will OpenID always constrain itself to areas where traditional
> > PKI vendors have played (authentication) and avoid areas where PKI
> > can't tread (authorization)?
> 
> Hi James
> 
> Authentication and authorization are somewhat overloaded words and
> different people mean different things by them. I recall you sending
> out a link to a set of requirements you had helped create. The
> dynamics of this mailing list tend to support concise use case
> discussion rather delve into large documents. A concise use case of
> what you mean by Authorization may prove useful to guide the
> discussion and work.
> 
> -- Dick
> 
> ___
> 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

RE: Proposal for Modularizing Auth 2.0 Discovery

[Gabe Wachob]

OK, I see what you are saying.

To be clear, what I was proposing was more like what we are doing with XRi -
xri.net or any XRI proxy you configure locally (e.g. http://xri.net/=GabeW
or http://xri.mydomain.com/=GabeW). The domain is not dependent on the
identifier - so in the email example, id we have [EMAIL PROTECTED] - the 
proposal
would be http://yourlocalopenidproxy.com/[EMAIL PROTECTED] (do we have to escape
the @? I'd have to go check), not something like http://foo.com/user
(although that was someone else's proposal). 

I'm just trying to suggest some uniformity or at least guidance for people
wanting to use new schemes with OpenID. So far, nobody seems to think its
needed? 

-Gabe

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark Baker
> Sent: Friday, March 02, 2007 10:26 PM
> To: Gabe Wachob
> Cc: specs@openid.net
> Subject: Re: Proposal for Modularizing Auth 2.0 Discovery
> 
> On 3/2/07, Gabe Wachob <[EMAIL PROTECTED]> wrote:
> > Hi Mark-
> > I think I understand your first point. I think FTP is a
> degenerate
> > case though, because its just like HTTP in the sense that there's
> basically
> > one way that everybody knows how to use an FTP URI to get at a
> *document*
> > (e.g. the FTP protocol) -- in that way, its just like HTTP. Besides,
> nobody
> > has a reason to use FTP URIs (though I'm sure someone will show me why
> I'm
> > wrong!)
> 
> Sure, but ftp was just an example.  There might be any number of new,
> useful URI schemes deployed in the future which become easily
> dereferenceable.
> 
> > As for URI squatting, I'm just not seeing the connection here.
> Who's
> > squatting here on what URI space?
> 
> Time for an example I suppose ...
> 
> I own markbaker.ca., and publish http URIs in that namespace.  I might
> (I don't) also have email addresses there, say [EMAIL PROTECTED]  If
> a public standard were crafted which defined a mapping for
> mailto:[EMAIL PROTECTED] to something under http://markbaker.ca (say,
> http://markbaker.ca/~mark), then by virtue of minting a new
> markbaker.ca email address, the corresponding http URI is now
> effectively reserved, and unavailable for me to use as anything other
> than an alias.
> 
> There's also existing namespaces to consider, as such a mapping spec
> would be affecting all existing published URIs, not just new ones.
> What if I already had both http://markbaker.ca/~foobar and
> mailto:[EMAIL PROTECTED], but both were unrelated?
> 
> It's not "squatting" in the sense of a person other than me reserving
> a name in my own space - at least not if the mapping is done to
> prevent that from happening (which won't be trivial for schemes which
> don't use the DNS).  But it's squatting in the sense that some
> external force (the mapping spec) prevents me from using my namespace
> the way I want.
> 
> I suggest just saying that any URI can be used, and let the
> community/market decide what actually gets used.
> 
> 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: Proposal for Modularizing Auth 2.0 Discovery

[Gabe Wachob]

Hi Mark-
I think I understand your first point. I think FTP is a degenerate
case though, because its just like HTTP in the sense that there's basically
one way that everybody knows how to use an FTP URI to get at a *document*
(e.g. the FTP protocol) -- in that way, its just like HTTP. Besides, nobody
has a reason to use FTP URIs (though I'm sure someone will show me why I'm
wrong!) 

I'm really making the argument that HTTP is special *because* the
document retrieval protocol is so associated with the URI (and widely
deployed, implemented, etc) - FTP is very similar in that sense but "It Just
Ain't HTTP". 

I think the example of email addresses is more appropriate - there
has been a lot of discussion about converting email addresses to descriptor
documents using SMTP extensions, using HTTP conventions (along the lines
what I'm proposing), etc. Even if there's a mailto: URI scheme, we don't
have a defined way with SMTP to retrieve descriptor documents, so the OpenID
folks have to define one if they want to use Email addresses as identifiers.
(I spose others could, but that's not happening).

I'd rather the complexity imposed on developers to support these
other identifiers be as simple as constructing HTTP URIs. They should be
free, of course, to use another way of resolving those identifiers (e.g. the
SMTP extensions mentioned earlier) if that's the way the community also
defines resolution to happen (in a "native" sense). 

I also agree with someone else's comment that the MUST wording I
have is probably not appropriate. So, if someone doesn't provide an HTTP
gateway definition in their specification, then so be it - makes it much
harder to adopt. 

As for URI squatting, I'm just not seeing the connection here. Who's
squatting here on what URI space? 

-Gabe

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark Baker
> Sent: Friday, March 02, 2007 8:50 AM
> To: Gabe Wachob
> Cc: Drummond Reed; Martin Atkins; specs@openid.net
> Subject: Re: Proposal for Modularizing Auth 2.0 Discovery
> 
> Hi Gabe,
> 
> On 2/28/07, Gabe Wachob <[EMAIL PROTECTED]> 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.
> 
> I don't understand that.  Why shouldn't, say, an ftp URI be usable as
> an ftp URI instead of converted to an http URI?
> 
> My bigger concern though, is that such a mapping would be a case of
> URI space squatting.
> 
> http://esw.w3.org/topic/UriSpaceSquatting
> 
> 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

Proposal for Modularizing Auth 2.0 Discovery

[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*}/? 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

CROSS POSTING :-(

[Gabe Wachob]

This is getting a little insane - many of us are subscribed to the four
lists that this thread has been posted to. 

One person has suggested that we actually consolidate the separate lists
given the overlap in membership and topics (at least the openid lists). The
other option is to be more disciplined about posting.

In any case, having most threads cross posted to 4 lists seems insane and
unworkable to me.

What's the mood on consolidating the lists? I'd rather we just be careful
about cross posting and keep the separate lists, but that may be too much to
ask. 

-Gabe

P.S. Yes, I realize this is cross posted ;-)

> -Original Message-
> From: Marcin Jagodziński [mailto:[EMAIL PROTECTED]
> Sent: Monday, January 22, 2007 10:47 AM
> To: Ben Laurie
> Cc: Josh Hoyt; [EMAIL PROTECTED]; specs@openid.net; openid-general;
> heraldry-dev@incubator.apache.org
> Subject: Re: [security] [OpenID] Announcing OpenID Authentication 2.0 -
> Implementor's Draft 11
> 
> 2007/1/22, Ben Laurie <[EMAIL PROTECTED]>:
> > Actually, it appears to allow the RP to tell the OP what kind of
> > authentication was used, which is backwards.
> >
> > It also seems to be rather lacking in meat. Still, a step in the right
> > direction.
> >
> 
> I asked this question some time ago: is there any possibility for RP
> to ask OP to use some authentication method? Or another scenario: how
> can user select one of OP's for this particular authentication from
> his Yadis file.
> 
> regards,
> 
> Marcin

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

RE: [OpenID] OpenID IPR Policy Draft

[Gabe Wachob]

Yes, you missed #4.

I think #3 is still a debatable point. It causes *problems* for open source,
but those problems are dealt with today -- at least from what I see. I agree
with Ben Laurie that it would be much better if the automatic creation of a
license could be made to happen, but there are some practicalities legally
and procedurally (when does a license come into being? Does this mean that
everyone with IPR that needs to be licensed has to agree to the exact same
license?) that could make imposing this difficult. 

This is definitely one of the first topics that we can discuss with
appropriate legal counsel if we choose to go that direction before we take
OpenID to a standards organization that has already solved these issues (or
not, according to Ben). 
  

-Gabe

> -Original Message-
> From: Recordon, David [mailto:[EMAIL PROTECTED]
> Sent: Thursday, December 21, 2006 11:27 AM
> To: [EMAIL PROTECTED]; Gabe Wachob
> Cc: specs@openid.net
> Subject: RE: [OpenID] OpenID IPR Policy Draft
> 
> So just circling back on this, summarizing the key points I saw from the
> discussion.
> 
> 1) We can't directly take the IPR Policy from a SDO (such as the W3C)
> and use it verbatim.  Those policies are tied to the specific SDO's
> policies and procedures which we'd also have to adopt in order to be
> useful.
> 2) The trigger for disclosure has to be active, not passive.
> 3) Just requiring issuance of a license is not strong enough to support
> Open Source implementations.  Rather needs to be worded along the lines
> of "a unilateral license or covenant of non-assertion (etc) that does
> not require affirmative action on the part of the licensee".
> Microsoft's Open Specification Promise is viewed by members of the IETF
> community as the clearest expression of this.
> 5) The OpenID community could theoretically patent its own work to
> prevent someone else from trying to claim the invention.
> 
> I miss anything?
> 
> --David
> 
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of Recordon, David
> Sent: Wednesday, December 06, 2006 2:43 PM
> To: [EMAIL PROTECTED]
> Cc: specs@openid.net
> Subject: [OpenID] OpenID IPR Policy Draft
> 
> 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
> 
> 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: [OpenID] Opened IPR Policy Draft

[Gabe Wachob]

Well said Phill. 

We'd like to take an off-the-shelf policy that is comes with an
off-the-shelf process (the two are very intertwined) that produces
specifications that can be taken to more established SDOs. Once this thing
exists, this IPR discussion can be very much quicker.

As you've noted in earlier emails, the landscape is still changing, and even
the SDOs are just now getting their arms around the optimal IPR policies for
themselves. But because these IPR policies are based on concepts like
"membership" and "termination of membership" and "votes to approve
contributions", we can't simply import them wholesale, unless we adopt those
process concepts as well. 

I'd like to have the one IPR policy/process to rule them all (at least for
open community-based standards like OpenID). We're not there yet. Maybe
we're making steps in the right direction, though.

-Gabe



> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of Hallam-Baker, Phillip
> Sent: Tuesday, December 12, 2006 11:12 AM
> To: David Nicol; James A. Donald
> Cc: Martin Atkins; Gavin Baumanis; specs@openid.net; [EMAIL PROTECTED]
> Subject: Re: [OpenID] Opened IPR Policy Draft
> 
> The problem is not the people who contribute, it's the ones who never join
> the group or agree to any license because they never intend to make or
> sell anything.
> 
> Align with the standards bodies, that way we have the option of going to a
> standards body later.
> 
> I have been through the pain here... The concern I have is that we don't
> end up in the situation that caused one of my standards groups I was
> trying to form to implode during formation.
> 
> I want to standardize the legal part of the process. Mozilla is not a good
> model, there are ideological commitments there which are not widely
> appreciated and in certain quarters distinctly unappreciated.
> 
> 
> 
> > -Original Message-
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] On Behalf Of David Nicol
> > Sent: Tuesday, December 12, 2006 2:02 PM
> > To: James A. Donald
> > Cc: specs@openid.net; Martin Atkins; Gavin Baumanis;
> > [EMAIL PROTECTED]
> > Subject: Re: [OpenID] Opened IPR Policy Draft
> >
> > On 12/12/06, James A. Donald <[EMAIL PROTECTED]> wrote:
> > > 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.
> >
> > What a headache.  Let's get whoever makes the best reference
> > implementation to release it MPL.  Mozilla PL has viral
> > patent grant language in it while explicitly allowing MPLd
> > code to be included in "Larger Projects."  (not sure about
> > the viral nature of the patent grant language; if we want a
> > viral patent grant we might have to create the OIDPL or something)
> >
> >
> >
> > --
> > perl -le'1while(1x++$_)=~/^(11+)\1+$/||print'
> > ___
> > specs mailing list
> > specs@openid.net
> > http://openid.net/mailman/listinfo/specs
> >
> >
> ___
> general mailing list
> [EMAIL PROTECTED]
> http://openid.net/mailman/listinfo/general

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

RE: [OpenID] OpenID IPR Policy Draft

[Gabe Wachob]

James-

Yes, you're correct. We can't control people who aren't covered by the
policy and they can often be the ones who (legitimately or not) have IPR
claims that can disrupt our work. 

We *can* however, take care of the cases where someone joins the group and
actively promotes a technology decision based not on technical merit, but
rather based on a desire to generate licensing revenue (or other market
influence) based on their patent claims. 

Unfortunately, there's risk no matter what we do - the attempt here is to
reduce the risk as much as is practical given the loose process and open
community focus we have. 

-Gabe

> -Original Message-
> From: James A. Donald [mailto:[EMAIL PROTECTED]
> Sent: Friday, December 08, 2006 9:31 PM
> To: Gabe Wachob
> Cc: 'Martin Atkins'; [EMAIL PROTECTED]; specs@openid.net
> Subject: Re: [OpenID] OpenID IPR Policy Draft
> 
> 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

[Gabe Wachob]

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?) 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). 

-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: OpenID IPR Policy Draft

[Gabe Wachob]

Actually, the language was changed from "post to a list", not "subscribe to
a list" for this very reason. 

Our intent was to come up with another simple trigger that didn't involve a
lot of process (and was clear and not subject to much interpretation) and
decided that this was a reasonable first cut (the act of posting to the
list). What other simple trigger would you suggest? How do you define
"contribution"? Who defines contribution? This is fuzzy line here - we were
trying to enclose the largest scope of contributions to minimize questions
later on whether or not an idea was "contributed" or not (e.g. a
patent-covered claim can be incorporated in a specification whether or not a
patent owner actually contributes *text*). 

This stuff is rather complicated and since we are not doing it within the
confines of a traditional standards body, we either have to take the time to
do a formal IPR policy which implies more formal process (introducing
friction to wider community participation), OR we have to have a IPR policy
that acknowledges the loose procedure we are using and recognizes the risk
of this approach with respect to IPR disclosure and licensing. There's no
free lunch here. 

The one thing I think we really should avoid is recreating a more formal
standards body from scratch - its hard work and these bodies already exist.
If this community really believes that we need the more formal process and
IPR policy, then we should consider taking this effort to a standards body
like OASIS *now* rather than later. 

I think a number of us working on this hoped that we could get this work to
an implementable state sooner than it would be practical to move to a formal
standards body. The current work on IPR policy is a stopgap measure until
such a time that we decide to take the work to a more formal standards body.
 

-Gabe



> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
> Of Martin Atkins
> Sent: Thursday, December 07, 2006 10:54 AM
> To: [EMAIL PROTECTED]; specs@openid.net
> Subject: Re: OpenID IPR Policy Draft
> 
> Recordon, David wrote:
> >
> > http://openid.net/wiki/index.php/IPR_Policy
> >
> 
> Is it really possible to use mailing list subscription as a trigger for
> a contract like this? The whole idea scares me a little bit, to be honest.
> 
> It seems more sensible to me to put these restrictions on actual
> *contributions*: require that any proposal or concrete
> specification/implementation offered via the mailing lists or other
> "official" channels to come with patent disclosure, and only *then* are
> any undisclosed patents assumed to constitute a royalty-free, perpetual
> licence.
> 
> As it is currently written, I think lots of companies that retain
> software patents of any kind - or even ones that don't but may wish to
> in the future - would be put off contributing due to the risk that their
> patents may be implicitly licenced to everyone.
> 
> I'm not a lawyer, of course. However, not everyone who could potentially
> be affected by this is a lawyer either, so putting in stuff that
> potentially scares non-lawyers like myself is probably a bad idea.
> 
> 
> ___
> 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 IPR Policy Draft

[Gabe Wachob]

The reason is easy - each of these organizations has a different process and
the IPR is intimately tied to process (for example, when certain disclosure
and licensing agreements come into force). 

 

In addition, some bodies offer a broader spectrum of levels of IPR
encumberance for the specs produced in each body. 

 

They actually don't differ much beyond this, however, and the spirit of the
respective IPR policies are converging.

 

-Gabe

 

  _  

From: Hallam-Baker, Phillip [mailto:[EMAIL PROTECTED] 
Sent: Thursday, December 07, 2006 10:20 AM
To: Gabe Wachob; Brett McDowell; Recordon, David
Cc: specs@openid.net; [EMAIL PROTECTED]
Subject: RE: OpenID IPR Policy Draft

 

Why not just take the W3C IPR policy verbatim and change the organization
name?

 

The W3C patent policy is I believe released under creative commons for
precisely this reason if not this can easily happen. The agreement was
subscribed to by all the major vendors and the major open source groups.

 

Unless someone wants to incorporate proprietary technology that they are not
willing to release the rights to as required by the W3C terms this is a
debate we don't need to have.

 

 

Ideally the Apache, Mozilla, OASIS, W3C and IETF IPR WGs would get together
and devise an industry standard acceptable to both Open Source and
proprietary vendors. The introduction of suspense licenses means that it is
not unthinkable that they would reach a common set of terms.


 


  _  


From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Gabe Wachob
Sent: Thursday, December 07, 2006 1:01 PM
To: 'Brett McDowell'; Recordon, David
Cc: specs@openid.net; [EMAIL PROTECTED]
Subject: RE: OpenID IPR Policy Draft

Brett-

We need to get consensus on what the community wants before we
take this to an attorney.. However, I've done these sorts of IPR policies
for standards efforts several times and I can tell you that the process of
working through these IPR policies is slow, painful and expensive. I think
presenting an "already baked" (ie already drafted by lawyers) IPR policy to
this community and asking for a up/down vote is not in keeping with the
spirit of this development process. 

-Gabe

 


  _  


From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Brett McDowell
Sent: Thursday, December 07, 2006 6:48 AM
To: Recordon, David
Cc: specs@openid.net; [EMAIL PROTECTED]
Subject: Re: OpenID IPR Policy Draft

 

This is normally lawyer work.  I recommend the companies & individuals
invested in OpenID immediately turn this exercise over to your legal counsel
to ensure your interests--and the interests of the community--are protected
appropriately. 

Does the new OpenID organization have legal counsel retained (I don't mean
volunteers, but actually hired)?  If not, that would be my second
recommendation.

--Brett

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

Thanks,
--David
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs




-- 
Brett McDowell +1.413.662.2744 

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

RE: OpenID IPR Policy Draft

[Gabe Wachob]

Brett-

We need to get consensus on what the community wants before we
take this to an attorney.. However, I've done these sorts of IPR policies
for standards efforts several times and I can tell you that the process of
working through these IPR policies is slow, painful and expensive. I think
presenting an "already baked" (ie already drafted by lawyers) IPR policy to
this community and asking for a up/down vote is not in keeping with the
spirit of this development process. 

-Gabe

 

  _  

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Brett McDowell
Sent: Thursday, December 07, 2006 6:48 AM
To: Recordon, David
Cc: specs@openid.net; [EMAIL PROTECTED]
Subject: Re: OpenID IPR Policy Draft

 

This is normally lawyer work.  I recommend the companies & individuals
invested in OpenID immediately turn this exercise over to your legal counsel
to ensure your interests--and the interests of the community--are protected
appropriately. 

Does the new OpenID organization have legal counsel retained (I don't mean
volunteers, but actually hired)?  If not, that would be my second
recommendation.

--Brett

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

Thanks,
--David
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs




-- 
Brett McDowell +1.413.662.2744 

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

RE: Delegation discussion summary

[Gabe Wachob]

*If* we are going to open up the terminology discussion, for me the terms
"authenticating party" (formerly the "IDP") and "accepting party" (formerly
the "relying party") seem more descriptive.  The authenticating party issues
authentication assertions in the form of special HTTP request/responses with
the other party, who then accepts these assertions and decides whether or
not they are good enough to let a user do something. 

As far as Dick's terminology, I'm not sure how "membersite" makes sense
here. Perhaps it's a matter of history or perspective that I haven't been
enlightened on. 

In any case, I'd rather get openid 2.0 out sooner than have a long
discussion on terminology, so I won't push this any further unless someone
else really thinks its valuable.

Gabe

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
> Of Graves, Michael
> Sent: Thursday, October 12, 2006 5:00 PM
> To: specs@openid.net
> Subject: RE: Delegation discussion summary
> 
> Josh, et al,
> 
> I believe the first of your options --  "Both portable and IdP-specific
> identifiers" -- is the superior choice here. It preserves OpenID 1
> semantics, and unambiguously makes room for portable identifiers. I
> don't see the added burden carried by relying party code for this option
> viz. portable identifiers only as being significant. Recommend we
> proceed with the "both" strategy.
> 
> Also, this may be throwing a wrench in the gears here, but I'd like to
> toss in the idea of using this point in time to pivot on our terminology
> and look at adopting Dick Hardt's terminology here. Portable identifiers
> are a powerful upgrade in and of themselves, and get us off the "IDP
> lock-in" hook that I've been hung up with customers on now a couple
> times. But as we move away from explicit IdP-specific URLs as the only
> identifier, I think that the Sxip "homesite" model becomes more
> important to consider as well. I very much like the idea of entiring in
> my "homesite" URL at a participating "membersite" (OpenID relying
> party), say "http://myidmanager.com"; and during the authentication
> process, being able to choose from one of n available personae managed
> for me by myidmanager.com. So my "final" identifier may be
> "http://myidmanager.com/73648729"; or even "http://graves.isnuts.com";.
> 
> I won't delve into where we are with respect to that capability here,
> but want to suggest that maybe as we move to OpenID 2.0, and now offer
> portable IDs (as well as run-time chosen IDs selected at auth-time?), we
> may be wise to just make the jump to using "homesite" and "membersite"
> across the board, rather than "IdP" and "relying party", both of which
> are technically problematic for our framework.
> 
> Anyway, that's a bit off topic, but something to consider.
> 
> In any case, the "both" option below gets my vote.
> 
> Good work Josh!
> 
> -Mike
> 
> 
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of Josh Hoyt
> Sent: Thursday, October 12, 2006 12:29 PM
> To: specs@openid.net
> Subject: Delegation discussion summary
> 
> Hello, list,
> 
> I'm sure that another message in your inbox with "delegation" in the
> title makes most of you cringe, so I'm sorry for that.I hope that this
> one gets us closer to resolving this issue.
> 
> I have attempted to summarize the proposed delegation mechanisms, as
> well as the currently-specified delegation mechanism in a single
> document. I have glossed over some issues and left out some of the
> discussion, but I hope that I captured most of the important stuff.
> After reviewing the discussion, I think that we are actually pretty
> close to consensus on a course of action.
> 
> I have added one new thing in this write-up, which is that I have
> started calling "delegation" "portable identifier support", which gives
> rise to the term "portable identifier" for what is currently called a
> "delegated identifier." I think that this terminology is a little easier
> to understand and less loaded than calling it "delegation."
> 
> My write-up follows.
> 
> Josh
> 
> OpenID portable identifier support
> ##
> 
> Portable identifier support allows an IdP to do authentication for an
> identifier that was not issued by that IdP. It has two motivating use
> cases [1]_:
> 
>   * allow users to use any identifier with any IdP
> 
>   * allow users to move an identifier between IdPs (prevent IdP lock-in)
> 
> Each portable identifiers has an IdP-specific identifier tied to it.
> This identifier allows the IdP to know what credentials to require
> before issuing an authentication response even though the IdP does not
> control the portable identifier.
> 
> Throughout this discussion, I will assume that there is a portable
> identifier called "http://my.portable.url/"; that uses an IdP-specific
> identifier called "http://my.idp.specific.url/";.
> 
> 
> Current implementation
> 

RE: [PROPOSAL] Separate Public Identifier from IdP Identifier

[Gabe Wachob]

What does Liberty call it?

(Gabe ducks..)

Some humor for a Friday...

-Gabe

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
> Of Martin Atkins
> Sent: Friday, October 06, 2006 9:42 AM
> To: specs@openid.net
> Subject: Re: [PROPOSAL] Separate Public Identifier from IdP Identifier
> 
> Dick Hardt wrote:
> >
> > I think "Token" is not a good name, so many other meanings. Perhaps
> > "handle"?
> >
> 
> I agree that "token" is not the best name. "handle" is still not that
> specific, but at least it isn't used in too many other places.
> 
> (We do already have an "assoc_handle", however.)
> 
> ___
> 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: Strong Authencation (was [PROPOSAL] authentication age

[Gabe Wachob]

I don't think it will get ugly because I think there are many ways to layer
on the functionality we are talking about. 

For example, Visa has something called 3-D Secure which is similar in many
ways to OpenID using INames. Instead of keying authentication off of INames,
they use Credit Card numbers. 

3-D Secure is implemented in one of several programs - Visa has "Verified by
Visa", Mastercard has "Securecode". Each of these programs varies the
protocol slightly, but by in large, the authentication mechanisms are
enforced by *policy* (ie you MUST use auth at least as strong as this) and
that policy is enforced (among several methods) by 1) the fact that
communication with the (credit card) directory requires clients to
authenticate *to the directory* and 2) the back channel communication is
mediated through the directory. That is one mechanism (which I really don't
recommend) that OpenID could take. 

Dick suggested a method where there is some vendor providing strong
authentication which is verifiable by anyone (or at least anyone who is part
of the club and cares). That authentication proof could ride along as an
extension element in OpenID. I suggested another approach where IDP's
themselves were "part of a club" (and there could be any number of clubs)
and that proof that the *IDP* was part of the club could come along as an
extension to the OpenID data. 

And if you are worried about how the RP knows ahead of time that an IDP can
provide the requisite extensions, we have a mechanism in the XRDS to
advertise these facts. 

So I think all these pieces are there -- it's just a matter of figuring out
how to put them together for the specific scenarios we have. I think in fact
that there will not be *one* answer, but several -- each based on the
ecosystem involved. If electronic payments systems ever use OpenID, there
will be certain controls that everyone who is participating will have to
agree to, and those controls may have to be enforceable and auditable by
multiple parties. In other scenarios, only certain parties may care (ie
RP's) and it may be untenable to impose as many extension pieces.

But I think we're getting ahead of ourselves. As long as you believe the
extensibility is in there and there is a reasonable path forward, then we
should get the basic infrastructure gelled and rolled out soon, or else
we'll never get the experience and mindshare with OpenID that we want. 

The quicker we get today done, the quicker we can get to tomorrow. 

-Gabe


> -Original Message-
> From: Chris Drake [mailto:[EMAIL PROTECTED]
> Sent: Thursday, October 05, 2006 10:22 AM
> To: Dick Hardt
> Cc: Gabe Wachob; 'Kevin Turner'; specs@openid.net
> Subject: Re: Strong Authencation (was [PROPOSAL] authentication age
> 
> Hi All,
> 
> 1. Amazon asks the IdP "Please assert this user is not a Robot"
>How can it trust this occurred?
> 
> 2. Amazon asks the IdP "Please re-authenticate this user, via
>two-factor, two-way strong authentication"
>How can it trust *this* occurred?
> 
> The IdP can *say* it did, but would RPs prefer a "stronger" role to
> encourage adoption? (eg: #1 - the RP provides the captcha, and the
> hash of the solution, while the IdP returns the solution, or #2 - the
> RP provides a nonce and later looks for this nonce in the IdP's
> also-signed-by-the-authentication-vendor-technology response)
> 
> i.e.: It might get ugly to try and add this stuff in later if we've
> not catered up-front for these kinds of interchanges.
> 
> Kind Regards,
> Chris Drake

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

RE: Strong Authencation (was [PROPOSAL] authentication age

[Gabe Wachob]

Dick
That's sounds like a reasonable approach (if I understand what you
are saying), and frankly one I hadn't considered.
More importantly, it sounds like we agree that we expect this to lie
in the domain of OpenID extensions and that we don't need to consider these
scenarios/requirements now for the 2.0 specs?

-Gabe

> -Original Message-
> From: Dick Hardt [mailto:[EMAIL PROTECTED]
> Sent: Thursday, October 05, 2006 9:36 AM
> To: Gabe Wachob
> Cc: 'Chris Drake'; 'Kevin Turner'; specs@openid.net
> Subject: Strong Authencation (was [PROPOSAL] authentication age
> 
> The vision I have is that strong authentication to your IdP will be
> common in the future.
> 
> The strong authentication will be supplied by a vendor that has been
> certified to provide standardized levels of authentication. The IdP
> will often NOT be the strong auth vendor.
> 
> The RP will have a trust relationship with the vendor, likely through
> a vendor consortium that delegates to vendors that their product is
> certified, ie. the RP will not need to trust each vendor, just the
> certification body.
> 
> I would hope that OpenID can be extended over time to be able to move
> around these types of strong auth assertions.
> 
> -- Dick
> 
> 
> On 4-Oct-06, at 8:41 PM, Gabe Wachob wrote:
> 
> > Chris-
> > As someone who has recently come from working in the financial
> > sector (Visa), its clear that OpenID is NOT intended for
> > authentication
> > where the *relying party* cares about how the authentication is
> > performed.
> >
> > At places like Visa and for home banking, this means that OpenID,
> > without something more, is clearly a non-starter. These relying
> > parties want
> > to know exactly how their users are being authenticated because their
> > business is all about risk management and creating business
> > opportunities
> > around very good knowledge of the risk profile of each transaction
> > type.
> >
> > That all being said, I believe it should be possible to layer on
> > OpenID a form of IDP control such that a relying party can require
> > a certain
> > class or group of IDPs be used when presenting authentication
> > assertions to
> > them. The actual *policy* for how these IDPs are approved is probably
> > orthogonal to the protocol spec, but "secure" identification of
> > those IDPs
> > (relative to some trust root, etc) could probably be made into an
> > extension
> > usable for those parties who want it.
> >
> > My guess is that culturally, most people involved in OpenID have
> > *not* been interested in addressing these concerns. However,
> > expectations
> > need to be better managed around these sort of "relying-party cares"
> > scenarios, because its not obvious without actually reading the specs
> > themselves...
> >
> > -Gabe
> >
> >> -Original Message-
> >> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> >> On Behalf
> >> Of Chris Drake
> >> Sent: Wednesday, October 04, 2006 8:26 PM
> >> To: Kevin Turner
> >> Cc: specs@openid.net
> >> Subject: Re[2]: [PROPOSAL] authentication age
> >>
> >> Hi Kevin,
> >>
> >> Sounds like you're leaning towards a root authority for IdPs who can
> >> audit procedures and verify protection in order to sign the IdP's
> >> keys?
> >>
> >> Joe blogger doesn't care much about identity assertions from an IdP,
> >> but it's a reasonable bet to expect that a Bank might care...
> >>
> >> Kind Regards,
> >> Chris Drake
> >>
> >>
> >> ___
> >> 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

RE: Re[4]: [PROPOSAL] authentication age

[Gabe Wachob]

Chris-
I don't mean to be pessimistic about OpenID *AT ALL* - I truly do
believe that OpenID *WILL* get to the point where its valuable for the Visas
of the world. I don't want to stall it for the other use cases that are
motivating the people who are currently involved - I think OpenID can
quickly evolve when needed. OpenID should be as lightweight as needed for
the use case - and I so I think OpenID is great where it is. 
Its just that we have to be clear what its trying to do today and
what it is NOT trying to do. I think we'll surprise some people (like you) -
but in the long run, the credibility will be there - I *KNOW* the folks who
are involved with OpenID are smart and know what it can and cannot do right
now. We just have to make sure that its being communicated clearly so
expectations aren't raised and then not met...

-Gabe

> -Original Message-
> From: Chris Drake [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, October 04, 2006 9:00 PM
> To: Gabe Wachob
> Cc: 'Kevin Turner'; specs@openid.net
> Subject: Re[4]: [PROPOSAL] authentication age
> 
> Hi Gabe,
> 
> Beautifully worded, and (IMHO) an extremely valuable real-world
> opinion.  I too believe OpenID is currently a "non-starter".  I have
> dual vested interests:  I want OpenID to succeed, *especially* for RPs
> like Visa, since my IdP makes money from supporting OpenID only when
> OpenID ends up getting used.  I also believe that an IdP (and mine in
> particular) is well suited for deploying secure technology (eg: two
> factor tokens).  If, aside from making OpenID actually *work* for the
> likes of Visa, we can build in the ability to provide a tangible
> *benefit* to Visa from using it (that is: allow visa to REQUIRE that a
> user has authenticate via two-factor means, to an accredited - i.e:
> explicitly trusted by Visa - IdP) then we've not only cemented the
> future of OpenID, we've gone an improved a pile of security problems
> along the way.
> 
> Kind Regards,
> Chris Drake
> 1id.com
> 
> Thursday, October 5, 2006, 1:41:34 PM, you wrote:
> 
> GW> Chris-
> GW>   As someone who has recently come from working in the financial
> GW> sector (Visa), its clear that OpenID is NOT intended for
> authentication
> GW> where the *relying party* cares about how the authentication is
> performed.
> 
> GW>   At places like Visa and for home banking, this means that OpenID,
> GW> without something more, is clearly a . These relying parties want
> GW> to know exactly how their users are being authenticated because their
> GW> business is all about risk management and creating business
> opportunities
> GW> around very good knowledge of the risk profile of each transaction
> type.
> 
> GW>   That all being said, I believe it should be possible to layer on
> GW> OpenID a form of IDP control such that a relying party can require a
> certain
> GW> class or group of IDPs be used when presenting authentication
> assertions to
> GW> them. The actual *policy* for how these IDPs are approved is probably
> GW> orthogonal to the protocol spec, but "secure" identification of those
> IDPs
> GW> (relative to some trust root, etc) could probably be made into an
> extension
> GW> usable for those parties who want it.
> 
> GW>   My guess is that culturally, most people involved in OpenID have
> GW> *not* been interested in addressing these concerns. However,
> expectations
> GW> need to be better managed around these sort of "relying-party cares"
> GW> scenarios, because its not obvious without actually reading the specs
> GW> themselves...
> 
> GW>   -Gabe
> 
> >> -Original Message-
> >> From: [EMAIL PROTECTED]
> >> [mailto:[EMAIL PROTECTED] On Behalf
> >> Of Chris Drake
> >> Sent: Wednesday, October 04, 2006 8:26 PM
> >> To: Kevin Turner
> >> Cc: specs@openid.net
> >> Subject: Re[2]: [PROPOSAL] authentication age
> >>
> >> Hi Kevin,
> >>
> >> Sounds like you're leaning towards a root authority for IdPs who can
> >> audit procedures and verify protection in order to sign the IdP's
> >> keys?
> >>
> >> Joe blogger doesn't care much about identity assertions from an IdP,
> >> but it's a reasonable bet to expect that a Bank might care...
> >>
> >> Kind Regards,
> >> Chris Drake
> >>
> >>
> >> ___
> >> 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: Re[2]: [PROPOSAL] authentication age

[Gabe Wachob]

Chris-
As someone who has recently come from working in the financial
sector (Visa), its clear that OpenID is NOT intended for authentication
where the *relying party* cares about how the authentication is performed. 

At places like Visa and for home banking, this means that OpenID,
without something more, is clearly a non-starter. These relying parties want
to know exactly how their users are being authenticated because their
business is all about risk management and creating business opportunities
around very good knowledge of the risk profile of each transaction type. 

That all being said, I believe it should be possible to layer on
OpenID a form of IDP control such that a relying party can require a certain
class or group of IDPs be used when presenting authentication assertions to
them. The actual *policy* for how these IDPs are approved is probably
orthogonal to the protocol spec, but "secure" identification of those IDPs
(relative to some trust root, etc) could probably be made into an extension
usable for those parties who want it. 

My guess is that culturally, most people involved in OpenID have
*not* been interested in addressing these concerns. However, expectations
need to be better managed around these sort of "relying-party cares"
scenarios, because its not obvious without actually reading the specs
themselves...

-Gabe

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
> Of Chris Drake
> Sent: Wednesday, October 04, 2006 8:26 PM
> To: Kevin Turner
> Cc: specs@openid.net
> Subject: Re[2]: [PROPOSAL] authentication age
> 
> Hi Kevin,
> 
> Sounds like you're leaning towards a root authority for IdPs who can
> audit procedures and verify protection in order to sign the IdP's
> keys?
> 
> Joe blogger doesn't care much about identity assertions from an IdP,
> but it's a reasonable bet to expect that a Bank might care...
> 
> Kind Regards,
> Chris Drake
> 
> 
> ___
> specs mailing list
> specs@openid.net
> http://openid.net/mailman/listinfo/specs

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