Re: Auth 2.0 spec errata regarding delegation vs. directed identity

2008-05-21 Thread John Ehn
Arrgh!  I'm horrible with names.  See below for corrected text.

On Wed, May 21, 2008 at 4:03 PM, John Ehn [EMAIL PROTECTED] wrote:

 Josh,

 I'm tending to agree with Martin on this one.  I guess that statement does,
 in a roundabout way, implies the Relying Party should do the following:

 * Run discovery against the Claimed Identifier (or use the cached response
 from a previous discovery), thereby determining the Local Identifier and
 endpoint URLs
 * If a Local Identifier is discovered, compare the Local Identifier with
 the openid.identity value in the assertion and verify they are the same - if
 they do not match, then authentication validation MUST fail
 * If a Local Identifier is not discovered, compare the Claimed Identifier
 with the openid.identity value in the assertion and verify they are the same
 - if they do not match, the Claimed Identifier MUST be ignored, and the
 value of openid.identity MUST be used instead

 I does not state this, though.  It is very much open to interpretation.

 Normative text needs to be very specific.  If you make a vague statement
 like you MUST verify what was received against what you already know, it
 can be interpreted very differently depending upon who is reading it.

 Honestly, my client implementation did not perform this check until Martin
 made mention of it on this list.  From what Martin states, it
 appears there several implementations are affected by this issue, which
 follows that the specification does not read as clearly as it should.

 Therefore, I suggest taking some action to correct the problem.  Sweeping
 this under the carpet will cause more harm than good.

 Thank you,

 John Ehn
 extremeswank.com


 On Wed, May 21, 2008 at 3:20 PM, Josh Hoyt [EMAIL PROTECTED] wrote:

 On Wed, May 14, 2008 at 11:20 AM, Martin Atkins [EMAIL PROTECTED]
 wrote:
   * The RP, when verifying that the openid.claimed_id URL in the
  assertion is valid, checks only that the openid2.provider value is
  correct, and doesn't check that the openid2.local_id value matches
  (after removing the fragment part) the openid2.identity URL.
 [...]
 
  Both of the above are currently allowed by the Auth 2.0 spec, but since
  doing the above checks doesn't seem to remove any useful possibilities,
  I think there ought to be some sort of errata that requires the checks
  I've listed above.

 The Verifying Discovered Information section[1] of the OpenID 2.0
 Authentication spec is actually pretty explicit about the fact that
 the relying party needs to verify this: If the Claimed Identifier is
 included in the assertion, it MUST have been discovered by the Relying
 Party and the information in the assertion MUST be present in the
 discovered information. It then goes on to list the information that
 must be verified.

 I think this is already covered.

 Josh

 http://openid.net/specs/openid-authentication-2_0.html#verify_disco
  ___
 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: Google OpenID is now live

2008-04-09 Thread John Ehn
I agree.  I think this is an excellent technology demonstration, but it is a
third-party, not Google, that is enabling the ID.

John

2008/4/9 Immad Akhund [EMAIL PROTECTED]:

 When Google eventually does make a proper OpenID provider all the OpenIDs
 provided by openid-provider.appspot.com would not match.

 Would get very confusing apart from advanced users that understand the
 distinction.

 Immad


 On Wed, Apr 9, 2008 at 12:49 PM, Paul Madsen [EMAIL PROTECTED]
 wrote:

  I expect Google might have a (legal) opinion on characterizing this
  application as 'Google OpenID'
 
  I think I'll wait for Google itself to enable my Gmail as an OpenID.
 
  paul
 
  Vinay Gupta wrote:
   http://openid-provider.appspot.com/
  
   Somebody used their app hosting service and implemented an OpenID
   provider.
  
   That kind of changes things, doesn't it?
  
   Vinay
  
  
  
  
  
  
  
  
   --
   Vinay Gupta - Designer, Hexayurt Project - an excellent public domain
   refugee shelter system
   Gizmo Project VOIP: 775-743-1851 (usually works!)
http://hexayurt.com/
   Cell: Iceland (+354) 869-4605
Skype/Gizmo/Gtalk: hexayurt
   People with courage and character always seem sinister to the rest
 Herman Hesse
  
  
  
  
  
   ___
   specs mailing list
   specs@openid.net
   http://openid.net/mailman/listinfo/specs
  
  
  
  
   No virus found in this incoming message.
   Checked by AVG.
   Version: 7.5.519 / Virus Database: 269.22.9/1365 - Release Date:
  4/8/2008 7:30 AM
  
 
  --
  Paul Madsene:paulmadsen @ ntt-at.com
  NTTp:613-482-0432
m:613-282-8647
aim:PaulMdsn5
web:connectid.blogspot.com
 
  ___
  specs mailing list
  specs@openid.net
  http://openid.net/mailman/listinfo/specs
 



 --
 Cell: +1 617 460 7271
 Skype: i.akhund
 Blog: http://immadsnewworld.com

 Clickpass, CTO
 ___
 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: Difference between 1.0 and 1.1

2008-03-12 Thread John Ehn
Anatoly,

1.0 was an informal specification, so it was prone to ambiguities.
1.1solved the majority of these problems, as it is clearer which
aspects of the
specification are optional and mandatory.

As far as I know, OpenID 1.1 is what all consumers should be supporting at
this point.

Thanks,

John Ehn
extremeswank.com


On 3/12/08, techtonik [EMAIL PROTECTED] wrote:

 Hi.

 What is the difference between OpenID authentication version 1.0 and 1.1?
 We need some arguments to switch preferable backwards compatibility scheme
 from 1.0 to 1.1 in Drupal. Looks like there is no way to detect which
 version of these two is used in case of HTML delegation and this causes
 problems between Drupal 5 and Blogger, because Drupal chooses 1.0 in this
 case.

 WBR,

 --
 --anatoly t.
 ___
 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: Difference between 1.0 and 1.1

2008-03-12 Thread John Ehn
On 3/12/08, techtonik [EMAIL PROTECTED] wrote:

 So, if I understand correctly there is no way for consumer to detect which
 version - 1.0 or 1.1 is used in HTML delegation case, because delegation
 tags are the same, i.e.

 link rel=openid.server href=
 http://www.livejournal.com/openid/server.bml;
 link rel=openid.delegate href=http://exampleuser.livejournal.com/;
 so in my case Drupal consumer decides that either 1.0 or 1.1 version of
 specification is used and makes a request to OpenID server with openid.nsset 
 to either 
 http://openid.net/signon/1.1; or http://openid.net/signon/1.0;. But 
 1.1OpenID server doesn't know anything about
 openid.ns, because it was added only in 2.0  Therefore server fails to
 authenticate and this should be considered a bug in consumer, which should
 not send openid.ns at all. If everything above is right then where is the
 logic and what are the reasons for consumer to send openid.ns=
 http://openid.net/signon/1.1; at all?

 Thank you.



Just to add my 2 cents, that namespace was introduced so you can discover an
OpenID Server using XRI.  That would be in the XRDS document to advertise
that the OpenID Server supported a specific version of the spec.  Since
OpenID 2.0 incorporates the XRI feature (which was a sort of third-party
add-on to the OpenID 1.x spec), that namespace is still used.

But, like James said, you shouldn't use openid.ns with 2.0 anyway.

Thanks,

John Ehn
extremeswank.com
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs


Re: Login Federation

2008-02-20 Thread John Ehn
Sounds like fun.  But I don't think I have the energy to go through a
process like that to get a extension spec registered.

If anyone wants to take the spec and run with it, they are welcome to.

Thanks,

John


On 2/20/08, Nat Sakimura [EMAIL PROTECTED] wrote:

 Actually, there seems to be.

 I was reading through the documents today and found about it.

 http://openid.net/ipr/OpenID_Process_Document_(Final_Clean_20071221).pdf

 Basically,

 1. Contributors for the new spec Sign the Contribution Agreement and
 gather more than five proposed WG members.
 2. Apply for a new Work Group to specs@openid.net
 = This needs to fulfil certain requirement.
 3. Get the approval from the Specification Council which is composed of
 two board members and five current and ex-editors (Eligible Editors).
  Who are the members of the current Specification Council?
 4. Start WG. Spec needs to go through three stages process:
 Draft - Implementors Draft - Final
 Basically, WG needs concensus to propose the spec to be implementors
 draft etc.
 to the members.After certain review period, members get to vote.
 The quorum is greater of 20% of OIDF members or 20 OIDF members.

 Regards,

 =nat

 Brett Carter wrote:
  John Ehn wrote:
 
  Sounds good.  I'm working on a draft.  Once it's in a readable state,
  I'll post it for comments.
 
  Thanks!
 
 
  Is there a formal process for submitting a proposal yet?  Or are we just
  going with RFC format for now?
  -Brett
  ___
  specs mailing list
  specs@openid.net
  http://openid.net/mailman/listinfo/specs
 

 --
 Nat Sakimura (=nat)
 Nomura Research Institute, Ltd.

 ___
 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: Login Federation

2008-02-20 Thread John Ehn
During the session cookie request, we are notifying the RP of the isLoggedIn
attribute.  The RP will already have this value (along with the
matching OpenID Identifier) because it was notified of the value when the
isLoggedIn attribute was updated.  The RP can then build a cookie that
matches the User Agent to the Identitifier.

Because AX unsolicited responses have to be verified with the OpenID
Provider, forcing the RP to look up the Identifier using the value of the
isLoggedIn attribute ensures that we are matching up to the correct
Identifier, and removes a potential security hole.

For RP-initiated log-out scenario, you can have the RP update the isLoggedIn
attribute using Attribute Exchange.  Since the change requires user
approval, this will ensure a rogue RP cannot accidentally log the user out.

Although browser extensions are great ideas, not all types of browsers can
load extensions.  For instance, a mobile phone or web tablet may not have
the ability to install Verisign's Seatbelt.  This is intended to be a way to
have SSO-like functions without modifying the User Agent.

Also, this is not technically a SSO implementation.  We are not assuring all
the RPs that this User Agent owns this OpenID.  Only that we think it does.
This means that each RP will have to perform its own (automated) OpenID
login process when the User Agent visits the site.  Since the cookie makes
it easy to figure out which OpenID Identifier to use, the process becomes
easy.

Thanks,

John

On 2/20/08, Tatsuya KATSUHARA [EMAIL PROTECTED] wrote:

 Thanks!

 1st: How to input OpenID implicitly.
 2nd: How to SLO from RP/OP(How to notify to RP or OP).

 For 1st, you issue site-specific session cookie and notify the value
 of *isLoggedin* attribute requested on the last? explicit login from
 RP and UA'll get the authenticated session cookie via IMG tag. I think
 federationId should include OpenID/iname, or RP get anonymous user's
 authenticated session. Do you mention it?

 Incidentally, I think it's enough that browser extention feeds OpenID
 to the form automatically and start with openid.mode=immedidate.

 For 2nd, what you say is good way. In fact SAML2.0 do SingleLogOut
 negotiation. To add another word, it would be good to add RP-initiate
 logout scenario.

 As I said, browser extention acheve to logout automatically. But
 SingleLogOut timing should be right unlike SingleSingIn in the view of
 security. If any, please let me know good ideas.


 In all honesty, I feel this draft is a little tricky, but whether
 OpenID that is low-coupled takes SingleSingIn/LogOut into spec or not
 is very interesting issue. I would like to know how do subscribers
 think...

 --
 =katsuhara http://xri.net/=katsuhara


 John Ehn wrote:
  I've posted a Draft 0 version to the OpenID Wiki.  Please feel free to
  comment and modify as needed.
 
  http://wiki.openid.net/Federation_Extension
 
  Thanks,
 
  John
 
  On 2/19/08, John Ehn [EMAIL PROTECTED] wrote:
  Brett,
 
  No formal process.  All RFC through the mailing list.
 
  Thanks,
 
  John
 
 
  On 2/19/08, Brett Carter [EMAIL PROTECTED] wrote:
  John Ehn wrote:
  Sounds good.  I'm working on a draft.  Once it's in a readable state,
  I'll post it for comments.
 
  Thanks!
  Is there a formal process for submitting a proposal yet?  Or are we
 just
  going with RFC format for now?
  -Brett
 
 
 
 
  
 
  ___
  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: Login Federation

2008-02-19 Thread John Ehn
Sounds good.  I'm working on a draft.  Once it's in a readable state, I'll
post it for comments.

Thanks!


On 2/19/08, Brett Carter [EMAIL PROTECTED] wrote:

  This is close to what I was thinking, however why not simply pass the
 user's open id url to the external site, through some yet undefined
 parameter.  This way, there's little chance for cache poisoning.  Passing
 the open id url, the consumer site can just proceed with authentication
 normally, using any cached data it has already.  Also, I think IMG tags are
 a better idea than IFRAMES, in another post.  They're more compatible, for
 one.


 A point I didn't think of at first is that we have the converse issue of
 being able to log out of federated sites as well.
 -Brett



  On Feb 18, 2008, at 11:58 AM, John Ehn wrote:

  I think I've figured out the flow.  It's seamless from the point of view
 of the user.  It will require explicit support from the Idenity Provider (on
 top of AX), and the client website will need to have an AX update receiver
 that supports this as well.  No special support is needed in the web
 browser.

 Turn on auto-logon on each site

 1. Log into the relying party normally
 2. Site begins OpenID authentication, sends AX request asking for the
 IsLoggedIn variable, and requests updates when the value changes.
 3. User selects whether or not they want this to occur (automatically
 notify the site upon login)
 4. From the user's point-of-view, login now occurs automatically at that
 site.

 Federated login

 1. User logs in to OpenID Provider
 2. IsLoggedIn variable is updated with a pseudo-random value
 3. All sites subscribing to the IsLoggedIn variable are updated using AX.
 4. OpenID Provider displays a page loaded with hidden iframes pointing
 to the same site URLs used for listening for AX updates. The IsLoggedIn
 variable is included as an argument.
 5. Each site's iframe performs regular OpenID authentication using
 the identity info already cached by the AX update receiver.
 6. As browser loads each iframe, it receives a standard login cookie from
 each site.
 7. User can connect to each site and will be automatically logged in.

 Federated logout

 1. User logs out of OpenID Provider
 2. IsLoggedIn variable is updated with a value of false
 3. All sites subscribing to the IsLoggedIn variable are updated using AX.
 4. Each receiving site expires the user session.

 Does this sound feasible?


 On 2/18/08, John Ehn [EMAIL PROTECTED] wrote:
 
  This can be pretty easily done by piggy-backing on the Attribute
  Exchange extension.  Have your OpenID Provider store a IsLoggedIn
  variable.  When the value is updated, the OpenID Provider can update all the
  websites subscribing to the value.
 
  The tricky part is having the web browser be automatically identifiable
  from all of these supported sites.  My first thought would be:
 
  * Store and send out the value in of the IsLoggedIn variable to all the
  websites
  * Give the browser multiple session cookies that are visible from each
  of the websites that the values was sent to, which contains a hash of the
  value plus the website URL.
  * When the website sees the cookie, it can take the cookie, generate and
  compare the hash.  If the hashes match, automatically do an OpenID login
  * When the user logs out at the OpenID Provider, AX will update all
  subscribing websites, thereby logging the user out of all sites
 
  Although, I believe most web browsers won't let you store cookies that
  are visible from multiple sites.  Perhaps someone more familiar with these
  mechanics and chip in?  Maybe somehow detect the web browser's signature
  without involving any functionality in the browser itself?
 
  Thanks,
 
  John Ehn
  extremeswank.com
 
   On 2/18/08, Martin Paljak [EMAIL PROTECTED] wrote:
  
  
   On Feb 18, 2008, at 5:11 PM, McGovern, James F (HTSC, IT) wrote:
Likewise, I would think that for automatic signon, it would be a
   good
thing if the OpenID provider could tell the relying party how long
   to
leave an otherwise idle session open before timing it out. Not sure
   if
this would require an extension or not.
  
   expires_in from
   http://openid.net/specs/openid-authentication-2_0.html#anchor20
   should do exactly this.
  
   m.
   --
   Martin Paljak
   http://martin.paljak.pri.ee
   +3725156495
  
  
   ___
   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: Login Federation

2008-02-19 Thread John Ehn
Brett,

No formal process.  All RFC through the mailing list.

Thanks,

John


On 2/19/08, Brett Carter [EMAIL PROTECTED] wrote:

 John Ehn wrote:
  Sounds good.  I'm working on a draft.  Once it's in a readable state,
  I'll post it for comments.
 
  Thanks!

 Is there a formal process for submitting a proposal yet?  Or are we just
 going with RFC format for now?
 -Brett

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


Re: Login Federation

2008-02-18 Thread John Ehn
This can be pretty easily done by piggy-backing on the Attribute Exchange
extension.  Have your OpenID Provider store a IsLoggedIn variable.  When
the value is updated, the OpenID Provider can update all the websites
subscribing to the value.

The tricky part is having the web browser be automatically identifiable from
all of these supported sites.  My first thought would be:

* Store and send out the value in of the IsLoggedIn variable to all the
websites
* Give the browser multiple session cookies that are visible from each of
the websites that the values was sent to, which contains a hash of the value
plus the website URL.
* When the website sees the cookie, it can take the cookie, generate and
compare the hash.  If the hashes match, automatically do an OpenID login
* When the user logs out at the OpenID Provider, AX will update all
subscribing websites, thereby logging the user out of all sites

Although, I believe most web browsers won't let you store cookies that are
visible from multiple sites.  Perhaps someone more familiar with these
mechanics and chip in?  Maybe somehow detect the web browser's signature
without involving any functionality in the browser itself?

Thanks,

John Ehn
extremeswank.com

On 2/18/08, Martin Paljak [EMAIL PROTECTED] wrote:


 On Feb 18, 2008, at 5:11 PM, McGovern, James F (HTSC, IT) wrote:
  Likewise, I would think that for automatic signon, it would be a good
  thing if the OpenID provider could tell the relying party how long to
  leave an otherwise idle session open before timing it out. Not sure if
  this would require an extension or not.

 expires_in from
 http://openid.net/specs/openid-authentication-2_0.html#anchor20
 should do exactly this.

 m.
 --
 Martin Paljak
 http://martin.paljak.pri.ee
 +3725156495


 ___
 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: Login Federation

2008-02-18 Thread John Ehn
I think I've figured out the flow.  It's seamless from the point of view of
the user.  It will require explicit support from the Idenity Provider (on
top of AX), and the client website will need to have an AX update receiver
that supports this as well.  No special support is needed in the web
browser.

Turn on auto-logon on each site

1. Log into the relying party normally
2. Site begins OpenID authentication, sends AX request asking for the
IsLoggedIn variable, and requests updates when the value changes.
3. User selects whether or not they want this to occur (automatically notify
the site upon login)
4. From the user's point-of-view, login now occurs automatically at that
site.

Federated login

1. User logs in to OpenID Provider
2. IsLoggedIn variable is updated with a pseudo-random value
3. All sites subscribing to the IsLoggedIn variable are updated using AX.
4. OpenID Provider displays a page loaded with hidden iframes pointing
to the same site URLs used for listening for AX updates. The IsLoggedIn
variable is included as an argument.
5. Each site's iframe performs regular OpenID authentication using
the identity info already cached by the AX update receiver.
6. As browser loads each iframe, it receives a standard login cookie from
each site.
7. User can connect to each site and will be automatically logged in.

Federated logout

1. User logs out of OpenID Provider
2. IsLoggedIn variable is updated with a value of false
3. All sites subscribing to the IsLoggedIn variable are updated using AX.
4. Each receiving site expires the user session.

Does this sound feasible?


On 2/18/08, John Ehn [EMAIL PROTECTED] wrote:

 This can be pretty easily done by piggy-backing on the Attribute Exchange
 extension.  Have your OpenID Provider store a IsLoggedIn variable.  When
 the value is updated, the OpenID Provider can update all the websites
 subscribing to the value.

 The tricky part is having the web browser be automatically identifiable
 from all of these supported sites.  My first thought would be:

 * Store and send out the value in of the IsLoggedIn variable to all the
 websites
 * Give the browser multiple session cookies that are visible from each of
 the websites that the values was sent to, which contains a hash of the value
 plus the website URL.
 * When the website sees the cookie, it can take the cookie, generate and
 compare the hash.  If the hashes match, automatically do an OpenID login
 * When the user logs out at the OpenID Provider, AX will update all
 subscribing websites, thereby logging the user out of all sites

 Although, I believe most web browsers won't let you store cookies that are
 visible from multiple sites.  Perhaps someone more familiar with these
 mechanics and chip in?  Maybe somehow detect the web browser's signature
 without involving any functionality in the browser itself?

 Thanks,

 John Ehn
 extremeswank.com

  On 2/18/08, Martin Paljak [EMAIL PROTECTED] wrote:
 
 
  On Feb 18, 2008, at 5:11 PM, McGovern, James F (HTSC, IT) wrote:
   Likewise, I would think that for automatic signon, it would be a good
   thing if the OpenID provider could tell the relying party how long to
   leave an otherwise idle session open before timing it out. Not sure if
   this would require an extension or not.
 
  expires_in from
  http://openid.net/specs/openid-authentication-2_0.html#anchor20
  should do exactly this.
 
  m.
  --
  Martin Paljak
  http://martin.paljak.pri.ee
  +3725156495
 
 
  ___
  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: Login Federation

2008-02-18 Thread John Ehn
Well, with some tweaking elsewhere.  Hidden iframes are the smoothest way to
do it.

On 2/18/08, John Ehn [EMAIL PROTECTED] wrote:

 It was just an example.  In theory, you could do it with an IMG or OBJECT
 tag.

 On 2/18/08, SignpostMarv Martin [EMAIL PROTECTED] wrote:
 
  John Ehn wrote:
   5. Each site's iframe performs regular OpenID authentication using
   the identity info already cached by the AX update receiver.
  
  Doable without iframes ?
 


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


Re: Integration with Enterprise Directory Services

2008-01-25 Thread John Ehn
James,

It appears you possess a good amount of knowledge on this topic.

I believe that if you were to come up with some preliminary  
implementation guidelines (and presented them here for review), you  
would not be stepping on anyone's toes.

Thank you,

John Ehn

On Jan 25, 2008, at 3:59 PM, McGovern, James F (HTSC, IT) [EMAIL PROTECTED] 
  wrote:

 Is there merit in also defining other aspects such as how the OP would
 store history in LDAP by defining new ObjectClass?


 *** 
 **
 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


OpenID 2.0 Section 9.2.1

2007-10-29 Thread John Ehn
I've been reviewing Draft 12, and noticed this section, which I think will
cause problems for some systems.


9.2.1.  Using the Realm for Return URL Verification

OpenID providers SHOULD verify that the return_to URL specified in the
request is an OpenID relying party endpoint. To verify a return_to URL,
obtain the relying party endpoints for the realm by performing *discovery on
the relying party (Discovering OpenID Relying
Parties)*http://openid.net/specs/openid-authentication-2_0-12.html#rp_discovery.
As always when performing discovery, the discovered URL is the URL of the
last HTTP response, following redirects. If any redirects are followed when
performing discovery on the realm, verification has failed. If discovery has
successfuly completed, check to make sure that the return_to URL matches one
of the relying party endpoints.

A realm may contain a wildcard, and so may not be a valid URL. In that case,
perform discovery on the URL obtained by substituting www for the wildcard
in the realm.

To match a return_to URL against a relying party endpoint, use the same
rules as for matching the return_to URL against the realm, treating the
relying party's endpoint URL as the realm. Relying party endpoint URLs MUST
NOT contain a domain wildcard, and SHOULD be as specific as possible.

*If verification is attempted and fails, the provider SHOULD NOT send a
positive assertion to that return_to URL. *

Providers MAY cache verified return_to URLs.

I think it is a nice idea, however, it does not take into account situations
where a Relying Party may not exist on the public Internet.  For instance,
let's say I have an intranet application.  The following is true:

   - The application is located on a host in my office
   - My office is connected to the Internet via a NAT firewall (all
   internal IP addresses are not accessible from the Internet)
   - My application uses OpenID for authentication
   - A guest worker has been given permission to use my application with
   their OpenID provided by another company

The following should happen:

   - The user will attempt to log in with their OpenID
   - My application will send a request to the OpenID Provider
   - The Provider will attempt to perform RP discovery
   - The RP discovery will fail
   - The OpenID Provider rejects the authentication request

As you can see, for this use case, OpenID would no longer be usable.

The first reaction will be well, this is a SHOULD, not a MUST.  That's all
well and good, however, this will cause any Intranet-based authentiation
request to fail for any provider that decides to implement this SHOULD,
which means we'll have minor frustration at least (you can switch to a
provider that doesn't implement this SHOULD), or abandonment of OpenID
entirely at worst.

I believe we should allow the user to be warned about the discrepency, but
all them to continue the authentication request if they are aware that RP is
not accessible from the Internet.

If I'm wrong, please let me know.

Thank you,

John Ehn
extremeswank.com
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs


Re: OpenID 2.0 Section 9.2.1

2007-10-29 Thread John Ehn
Okay.  Can we re-word it then so it's more explicitly stated?  I.E.:

Attempt discovery.
If discovery succeeds, ensure return_to URL is specified in the XRDS
document.  If not present, always return negative assertion.
If discovery fails, assume return_to URL is valid and return assertion.

Thanks!

John Ehn
extremeswank.com

On 10/29/07, James Henstridge [EMAIL PROTECTED] wrote:

 On 29/10/2007, John Ehn [EMAIL PROTECTED] wrote:
  I've been reviewing Draft 12, and noticed this section, which I think
 will
  cause problems for some systems.
 
 
  9.2.1.  Using the Realm for Return URL Verification
 
  OpenID providers SHOULD verify that the return_to URL specified in the
  request is an OpenID relying party endpoint. To verify a return_to URL,
  obtain the relying party endpoints for the realm by performing discovery
 on
  the relying party (Discovering OpenID Relying Parties). As always when
  performing discovery, the discovered URL is the URL of the last HTTP
  response, following redirects. If any redirects are followed when
 performing
  discovery on the realm, verification has failed. If discovery has
  successfuly completed, check to make sure that the return_to URL matches
 one
  of the relying party endpoints.
 
  A realm may contain a wildcard, and so may not be a valid URL. In that
 case,
  perform discovery on the URL obtained by substituting www for the
 wildcard
  in the realm.
 
  To match a return_to URL against a relying party endpoint, use the same
  rules as for matching the return_to URL against the realm, treating the
  relying party's endpoint URL as the realm. Relying party endpoint URLs
 MUST
  NOT contain a domain wildcard, and SHOULD be as specific as possible.
 
  If verification is attempted and fails, the provider SHOULD NOT send a
  positive assertion to that return_to URL.
 
  Providers MAY cache verified return_to URLs.
 
  I think it is a nice idea, however, it does not take into account
 situations
  where a Relying Party may not exist on the public Internet.  For
 instance,
  let's say I have an intranet application.  The following is true:
 
  The application is located on a host in my office
  My office is connected to the Internet via a NAT firewall (all internal
 IP
  addresses are not accessible from the Internet)
  My application uses OpenID for authentication
  A guest worker has been given permission to use my application with
 their
  OpenID provided by another company
  The following should happen:
 
  The user will attempt to log in with their OpenID
  My application will send a request to the OpenID Provider
  The Provider will attempt to perform RP discovery
  The RP discovery will fail
  The OpenID Provider rejects the authentication request
  As you can see, for this use case, OpenID would no longer be usable.

 From my reading of the spec, the OP only tries to verify the return_to
 value if RP discovery succeeds.  If RP discovery fails, then return_to
 verification is not attempted.

 In the case of an intranet RP (or any other RP that hasn't implemented
 discovery), any return_to URL that matches the realm should be
 acceptable.

 The case where the OP SHOULD NOT return a positive assertion is if:
 1. the OP attempts RP discovery
 2. RP discovery succeeds
 3. the return_to URL is not in the list of discovered RP endpoints

 James.

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


Re: An OAuth OpenID Extension

2007-10-24 Thread John Ehn
Joseph,

Any help you could provide to flesh out (or heavily modify) these specs
would be most appreciated.

Thanks,

John Ehn
extremeswank.com

On 10/22/07, Joseph Holsten [EMAIL PROTECTED] wrote:

 Wow, these are neat. Thanks for the links david, and especially the
 work john!

 OK, so the Inline Auth use case seems like a straightforward case for
 OAuth: resource url = identifier,  user auth url = delegate.
 Successfully accessing the resource after negotiation would imply
 that the user still trusts the RP. Seems like low hanging fruit.
 Also, gets the benefit of single sign off!

 I'm a little unsure about the best way for the Trusted Auth use case.
 This seems quite good, but a diagram of an oauth solution to the
 problem was on the mailing list not long ago. Same as the official
 diagram, but with a third column showing interactions between the
 Consumer Directs User to Service Provider and Service Provider
 Directs User to Consumer steps. I looked for half an hour, found
 nothing, but I'm not crazy really! Anyway, it would be nice to
 compare perspectives first.

 But if I remember correctly, the oauth proposal only allowed the
 Service Provider/Destination Consumer to revoke resource access,
 while openid trusted auth gives that right to the OP. Greater
 overhead versus greater user control.

 So who's interested in fleshing out these recommendations into specs?

 http:/ joseph holsten .com


 On 02007:10:22, at 3:54CDT, David Recordon wrote:

  Hey all,
  I know John did some work in September (http://extremeswank.com/
  openid_trusted_auth.html and http://extremeswank.com/
  openid_inline_auth.html).  Both solve extremely important use-cases
  and are becoming increasingly discussed especially with the advent of
  OAuth.  I'd really like to see how we can work to write an extension
  to OpenID Authentication where the OpenID Provider is also the one
  handling OAuth credentials.  This would be useful in the inline
  authentication use case as well as if we move to a deployment
  scenario where the OAuth Provider is checking with the user's OpenID
  Provider to verify OAuth signatures.  Overtime I also think moving
  OpenID to the OAuth signature mechanism would be beneficial, but I
  think that is a longer conversation.
 
  --David
 
  ___
  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: OpenID Inline Authentication Extension 1.0 Draft 1

2007-09-03 Thread John Ehn
Martin,

Thanks for the response!  I'm looking at those specs now, and I really like
the flow of the HTTP Authentication spec, because it looks like it's solving
the problem of passing the OpenID Identifier to the RP in an automated way,
which is really cool.  Looks like it needs to be fleshed out in some
parts, though.

As for the Signature Request protocol, I'm not quite sure what it does yet,
but I'll let you know my opinion once I've digested it.

Thanks!

John

On 9/3/07, Martin Atkins [EMAIL PROTECTED] wrote:

 John Ehn wrote:
  The Inline Authentication Extension attempts to solve the problem of
  legacy and interactive applications (Telnet/SSH) that are unable to
  launch a client Web Browser to perform an authentication request.
 
  http://extremeswank.com/openid_inline_auth.html
 
  This is done through the use of verification keys, which are
  provided either as needed by the OpenID Provider, or provided on a
  rotating basis from a hardware crypto device, or a key generating
  token (SecurID).
 
 Hi John,

 This is a good, well-written spec. It seems that it could be at home
 alongside OpenID HTTP Authentication[1] and possibly Signature Request
 Protocol[2], though I've not quite figured out exactly how they relate
 to one another yet. I think there may be some overlap between SRP and
 Inline Auth, since they are effectively trying to solve much the same
 problem.

 However, I'm wondering if Inline Auth addresses some or all of the
 concerns I described on the Signature Request Protocol wiki page. I'll
 look at this in more detail later, but if you'd like to comment that'd
 certainly make my life easier. :)

 [1] http://openid.net/wiki/index.php/OpenID_HTTP_Authentication
 [2] http://openid.net/wiki/index.php/Signature_Request_Protocol

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

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


OpenID Inline Authentication Extension 1.0 Draft 1

2007-09-01 Thread John Ehn
The Inline Authentication Extension attempts to solve the problem of legacy
and interactive applications (Telnet/SSH) that are unable to launch a client
Web Browser to perform an authentication request.

http://extremeswank.com/openid_inline_auth.html

This is done through the use of verification keys, which are provided
either as needed by the OpenID Provider, or provided on a rotating basis
from a hardware crypto device, or a key generating token (SecurID).

As always, your comments are appreciated!

Thank you,

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


Re: OpenID Inline Authentication Extension 1.0 Draft 1

2007-09-01 Thread John Ehn
Hans,

Yes, the Client App is expected to implement all the important parts of an
OpenID 2.0 Relying Party.  This means it will support XRI, Yadis, and HTML
discovery.

It's unlikely systems will have clashing namespaces, but is possible (most
corporate user accounts don't begin with =, @, +, etc, and most don't
use a format similar to URLs).  For a PAM implementation, the system would
likely give priority to all other authentication types, and fall back to
OpenID if there are no matches.  Or, the implementor may wish to prompt the
user for the authentication type, or provide instructions to add a special
prefix to the account name.

As for the wording in step 4, oops.  Thanks for catching that.  It should be
The user is prompted for their verification key, which is typed in and
submitted.

I have never personally done a PAM module, so I'm not a good fit.  I think
it would work very well though.  Know anyone who might want to give it a
try?

Thanks,

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


Re: OpenID Trusted Authentication Extension

2007-09-01 Thread John Ehn
On 8/31/07, James Henstridge [EMAIL PROTECTED] wrote:


 You still want the user involved in the granting of an authentication
 token though, right?  Trying to replace the UA in the authentication
 workflow is quite a big change, and limits what the OP can do.


Yes, granting the secret must be done using the traditional User Agent, as
the user must be logged in using their normal credentials in order for the
OP to deliver the secret to the requesting RP.

Considering it's an Extension, this isn't really any sort of change that
limits what the OP can do.  It simply codes a standard credential format
that is only used for when a site wishes to log into another site using a
specific OpenID.

With your proposal, the user's OP needs to implement an extension.
 This brings up a few questions:

 1. Should the data provider only let users register if their OP
 implements the extension?  What is the benefit to the data provider in
 enforcing such an extension?


Trusted Authentication doesn't require the destination site (the DP) to
implement any changes at all.  One would hope that the DP is offering some
valuable service other than just providing data to client sites.

As for the client site, yes, functionality will be lost if the OP doesn't
support the extension that would allow them to log in to another site.  If
the extension becomes popular, it would be in the best interest of the OP to
implement the extension if they wanted to keep users from switching to a
different provider that does support the extension.

2. If only some users' OPs implement the extension, can the data
 consumer rely on the protocol at all?


Why not?  They would be able to support this, and if the OP doesn't support
the extension, they can continue using those very insecure API key
implementations that are being used today.  Or, they can even suggest that
the user switch to a supporting provider.

In contrast, both the data provider and consumer have an incentive to
 implement an extension for auth token transfer, so a spec that only
 requires modifications to those parties seems easier to roll out.
 What do you think?


Well, as above, no changes are needed at the DP.  I think it would be much
easier to simply modify the hand-full of OPs and the Client RPs that want to
support the spec, which is expected with any OpenID extension.

[snip]
  to log on to the destination site to invalidate the token.  What if the
 user
  has 50 of these API connections set up?  That's 50 sites to visit in
 order
  to manage these tokens.

 I guess that is a concern.  But how often do you expect the data
 provider to check the user's OP to see if the token is still valid?
 If it doesn't check often, then revoking the token at the OP level
 might take a while to take effect.


Well, it really is up to the DP to determine how long it wants its sessions
open, just with any other website.  For instance, banks will automatically
expire the session if there is no activity for 15 minutes.  In this case,
the DP will simply force the Client RP to authenticate again with the OP.

As stated in the spec, it's not my intention to mandate how user data (and
the data session) is managed between the client RP and the DP.

Your feedback is always welcome.

Thanks,

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


Re: OpenID Trusted Authentication Extension

2007-08-31 Thread John Ehn
Well, I've slept on it.  I think we have a difference in philosophy.

The other Extesions - AX, Simple Registration, etc. - follow the same data
flow methodology:

RP - UA - OP
RP - UA - OP

I believe I'm sticking to the same principles in my spec.  We are doing the
very same thing when we collect the authentication key (see above).  We are
even doing the very same thing when we have the sites authenticate with each
other.  It's just we have a non-human operating the User Agent.  In this
case, the RP is the destination site, the UA is the client site:

RP - UA - OP
RP - UA - OP

I think this fits well with what people expect.  I also have no problem with
having OPs incrementally improve their systems to make them compatible with
new extensions.  Since there will (eventually) be far more RPs out there
than OPs, I think it's reasonable for them to support the bulk of the
extension implementation.

In this case, however, there really isn't all that much to implement.  The
following code changes will need to happen at the site that wants access to
information at another site (the CC):

* The form where the user submits their OpenID to grant permission to
another site
* Logic that builds a simple OpenID login request with the Trusted
Authentication data included, and a redirect to the OP
* A branch to the id_res checker that parses the OP response and stores
the shared secret
* An automated script that performs OpenID authentication to the DC and
retreives data

The OP needs to implement the following:

* When receiving a check_id request with Trusted Authentication arguments,
send an X-OPENID-TrustedAuthentication HTTP header in the response, and be
able to accept a SHA-256 hash as a response  - This is not a big deal, and
isn't any form of deviation, because this is the gray area in the spec
where the UA is supposed to be verified that it's already logged in, or is
prompted for credentials
* Add a logic branch that generates a shared secret when requested, stores
it, and sends it in the authentication response
* Some form of user interface to manage the stored secrets - very easy

All but one of these steps would be needed to implement ANY OpenID extension
out there.  And the only change that is out of spec is accepting an
SHA-256 hash as an authentication key - which is trivial to implement at an
OP.

Conservatively, (with distractions) I think an OP can implement the data
passing in less than a couple of hours, and the user interface in a couple
of days.

Although your implementation is sound, and I like a lot of the ideas, they
shift a lot of the responsibility to the party receiving the authentication
request.  I'm not sure I like the idea of having the burden of implementing
both an API and a special pseudo-OP.  This also removes the power of having
a single Identity management interface at the OP, meaning the user will have
to log on to the destination site to invalidate the token.  What if the user
has 50 of these API connections set up?  That's 50 sites to visit in order
to manage these tokens.

Like I said, nothing technically wrong with the idea (it's novel), but it
just doesn't fit with me.

Thank you!

John Ehn

On 8/30/07, James Henstridge [EMAIL PROTECTED] wrote:

 On 30/08/2007, John Ehn [EMAIL PROTECTED] wrote:
  James,
 
  Sorry, but I'm having problems following the flow.  It seems like an
  interesting idea, though.  Can you provide with a little more
 information on
  how these components would interact?

 Okay.  The basic idea was that instead of creating a special protocol
 for two OpenID relying parties to communicate with each other was for
 the web services data provider to act as an OpenID provider.

 So, lets assume that the data consumer wants an auth token for the
 user identified by http://user.identifier.url.  With normal OpenID
 authentication, you'd perform discovery to find the user's OpenID
 provider.  To request an auth token though we need to talk to the data
 provider, so instead we skip discovery and perform an authentication
 request to the data provider's endpoint.  The parameters might look
 something like this:

 * openid.mode = checkid_setup
 * openid.claimed_id = http://user.identifier.url
 * openid.identity = http://user.identifier.url
 * openid.return_to = http://data.consumer/. http://data.consumer/..
 * openid.ns.auth = ...
 * (additional parameters related to the auth token request)

 The data provider would then decide whether to grant the auth token
 (possibly by performing OpenID authentication against
 http://user.identifier.url, and/or asking the user), then send a
 response back like:

 * openid.mode = id_res
 * openid.claimed_id = http://user.identifier.url
 * openid.identity = http://user.identifier.url
 * openid.return_to = http://data.consumer/. http://data.consumer/..
 * openid.ns.auth = ...
 * openid.auth.token = ...
 * openid.auth.secret = ...

 The data consumer knows that the request came from the data provider
 due to the signature

Re: OpenID Trusted Authentication Extension

2007-08-30 Thread John Ehn
James,

Sorry, but I'm having problems following the flow.  It seems like an
interesting idea, though.  Can you provide with a little more information on
how these components would interact?

I was really trying to keep everything dumb and simple.  The concept I was
going for was piggy-back on OpenID, but include a way to programmatically
log on to the OpenID Provider.  The problem I saw with OpenID was that
there are about a million different ways to authenticate with an OpenID
Provider, from HTML forms to digital certificates.  Most require the User
Agent to be a web browser.  However, there is no standard way to just pass a
credential that can prove that you are who you say you are.

Trusted Connection Request:
User Agent gives OpenID to Client Consumer
Client Consumer - User Agent - OpenID Provider

Trusted Connection Response (with key):
Client Consumer - User Agent - OpenID Provider

Trusted Logon:
Client Consumer gives OpenID Identity to Destination Consumer
Destination Consumer - Client Consumer - OpenID Provider
Destination Consumer - Client Consumer - OpenID Provider

I was trying to solve the problem by coming up with an automatable (if
that's a word) way to authenticate with an OpenID Provider.  If we have
that, there's no need to pass around a special token, because we can
just use standard OpenID authentication if we want to log on to another
system.  So, I proposed just having the Consumer get a key from the OpenID
Provider that it can use to automatically authenticate with the Provider in
the future.  The key is passed through the user when it's granted, because
you need the user to approve the whole thing anyway.

I don't expect this extension to fix all problems.  It's only intended to
solve a specific use case (website to website info sharing).  I am working
on two additional extensions which will solve the other problems I see:

* Inline Authentication - Provide support for legacy and real-time
interactive systems that can't launch a web browser, and are protecting
their own data (Telnet, etc).  This will involve manually-typed verification
keys.
* Desktop Authentication - Provide for desktop applications
authenticating with and accessing data behind third-party systems (RSS
readers, chat, etc).

I appreciate any feedback you can give me.

Thank you!

John Ehn

On 8/30/07, James Henstridge [EMAIL PROTECTED] wrote:

 On 26/08/07, John Ehn [EMAIL PROTECTED] wrote:
  I have created a draft of a new specification that I think will help to
 fill
  a gap in OpenID functionality.
 
  What appears to be a newer productivity feature of many websites is the
  ability to import and utilize information from other sites.  For
 instance,
  Basecamp provides an API that allows other systems to access user data.
  This is a great feature, but it currently cannot be done with OpenID,
 due to
  the dependence on end-user interaction during the authentication
 process.
 
  The Trusted Authentication Extension provides for the ability for an
 OpenID
  Consumer to log in to another OpenID Consumer without user
 interaction.  The
  end user will be able to create a trusted connection between two OpenID
  enabled sites, which will allow a client site to access a destination
 site
  using the end user's Identity.
 
  Please provide your comments and feedback, as they are most appreciated.
 
  http://extremeswank.com/openid_trusted_auth.html

 I think things would be a bit clearer if you made the data provider
 into a form of OpenID Provider.

 I think it helps to first consider the case where the data provider is
 not an OpenID Relying party but instead has its own user account
 database.

 If the site acted as an OpenID provider, it would be pretty simple to
 use an extension to negotiate an auth token to acess data for the
 user.  Simply start an OpenID authentication request, including some
 field stating that you want access to data.  The provider would then
 include an authentication token in the response that could be used to
 access the web services.


 Now lets consider the case where the data provider identifies users by
 an OpenID.  What would happen if the data provider continued to
 implement an OP, and the data consumer started an OpenID
 authentication request with it using the user's data provider.

 This would let us use the same sort of OpenID extension to negotiate
 the auth token.  The data provider could even turn around and perform
 its own authentication request to verify that the user is who they say
 they are, since it received the identity URL from the data consumer.

 So the full workflow might go like this:

 DC: Data Consumer
 DP: Data Provider
 OP: User's OpenID Provider

 1. DC sends checkid_setup request to DP for user's identity URL, with
 an extension asking to negotiate an auth token.
 2. DP initiates OpenID authentication for user's identity URL
 3. OP verifies user's identity and sends idres reply to DP.
 4. DP sends idres reply to DC, including the auth token

Re: OpenID Trusted Authentication Extension

2007-08-30 Thread John Ehn
Ahhh, I see what you're going for.  It's a very interesting idea.

On 8/30/07, James Henstridge [EMAIL PROTECTED] wrote:

 On 30/08/2007, John Ehn [EMAIL PROTECTED] wrote:
  James,
 
  Sorry, but I'm having problems following the flow.  It seems like an
  interesting idea, though.  Can you provide with a little more
 information on
  how these components would interact?

 Okay.  The basic idea was that instead of creating a special protocol
 for two OpenID relying parties to communicate with each other was for
 the web services data provider to act as an OpenID provider.

 So, lets assume that the data consumer wants an auth token for the
 user identified by http://user.identifier.url.  With normal OpenID
 authentication, you'd perform discovery to find the user's OpenID
 provider.  To request an auth token though we need to talk to the data
 provider, so instead we skip discovery and perform an authentication
 request to the data provider's endpoint.  The parameters might look
 something like this:

 * openid.mode = checkid_setup
 * openid.claimed_id = http://user.identifier.url
 * openid.identity = http://user.identifier.url
 * openid.return_to = http://data.consumer/...
 * openid.ns.auth = ...
 * (additional parameters related to the auth token request)

 The data provider would then decide whether to grant the auth token
 (possibly by performing OpenID authentication against
 http://user.identifier.url, and/or asking the user), then send a
 response back like:

 * openid.mode = id_res
 * openid.claimed_id = http://user.identifier.url
 * openid.identity = http://user.identifier.url
 * openid.return_to = http://data.consumer/...
 * openid.ns.auth = ...
 * openid.auth.token = ...
 * openid.auth.secret = ...

 The data consumer knows that the request came from the data provider
 due to the signature on the OpenID response.  The data provider knows
 which user to create the token for because it was present in the
 OpenID request.  The data provider can verify that the web browser
 user is that user because control gets transferred to the data
 provider during the authentication process.

 This all assumes that the data consumer has already authenticated the
 user, so knows which identity URL to request a token for from the data
 provider.

  I was really trying to keep everything dumb and simple.  The concept I
 was
  going for was piggy-back on OpenID, but include a way to
 programmatically
  log on to the OpenID Provider.  The problem I saw with OpenID was that
  there are about a million different ways to authenticate with an OpenID
  Provider, from HTML forms to digital certificates.  Most require the
 User
  Agent to be a web browser.  However, there is no standard way to just
 pass a
  credential that can prove that you are who you say you are.

 Well, OpenID authentication requests are designed to let the OP
 perform whatever checking they want before sending a response.  So by
 making the data provider act as an OP, it has the same freedom
 (including the freedom to issue its own OpenID authentication request
 to the user's actual OP).

  I was trying to solve the problem by coming up with an automatable (if
  that's a word) way to authenticate with an OpenID Provider.  If we have
  that, there's no need to pass around a special token, because we can
 just
  use standard OpenID authentication if we want to log on to another
 system.
  So, I proposed just having the Consumer get a key from the OpenID
 Provider
  that it can use to automatically authenticate with the Provider in the
  future.  The key is passed through the user when it's granted, because
 you
  need the user to approve the whole thing anyway.

 I think that this makes things more complicated than need be.  If you
 want an auth token from the data provider it seems better to ask the
 data provider for the key directly, giving it the chance to
 authenticate the user before responding.

 This also has the benefit that it does not require any special
 features from the user's OP -- the extension is purely concerned with
 the interaction between data consumer and provider.


  I don't expect this extension to fix all problems.  It's only intended
 to
  solve a specific use case (website to website info sharing).  I am
 working
  on two additional extensions which will solve the other problems I see:

 Sure.  I doubt my suggested workflow would help with those use cases
 either (at least without some additional components).

 James.

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


Re: OpenID Trusted Authentication Extension

2007-08-29 Thread John Ehn
Chris,

I want to start off by saying how horribly inappropriate it is to use the
OpenID specifications mailing list to peddle an authentication standard that
has absolutely nothing to do with OpenID.

I find it interesting that so many of the OAuth community have taken time
out of their busy schedules to tell me to back off on my extension to
OpenID.  Every single response to my specification has mentioned OAuth, and
all with a very defensive tone.  Only one or two responses have had any
constructive criticism about the actual content of the specification.

To MY defense, I didn't even know about OAuth until I was reminded of it
in response to my specification.  I have attempted to review the spec, but
am unable to locate it anywhere, even though I joined the Google Group, as
requested.

Due to the very public negative response from the OAuth folks, I am tempted
to remove myself from the group as a result.

As for consensus, I simply don't care.  This was an exercise to allow OpenID
to fill the needs of a specific use case.  I believe it is extremely simple
to implement, and is reasonably secure.  If the OpenID folks decide to adopt
it, I will be very happy.  If not, I will still be happy.

I am passionate about OpenID.  I feel that if I want it succeed, I should
work to extend it, and I should have the freedom to do so.

Thank you,

John Ehn

On 8/29/07, Chris Messina [EMAIL PROTECTED] wrote:

 Hi John,

 Looks like there's some consensus around OAuth... ;)

 I helped to get OAuth off the ground to solve the very problem that
 you're looking to solve -- in our case, enabling Ma.gnolia OpenID
 users to use Dashboard Widgets and Twitter API users to authenticate
 their apps, eventually using OpenID.

 While I appreciate your work on an OpenID-specific extension, I think
 there's some legitimacy in looking at a solution that works generally
 regardless of the authentication mechanism. By decoupling OpenID and
 OAuth, the goal was to make it easier to adopt OAuth first and then
 lead into adopting OpenID.

 In the case of your spec, which seems like a good piece of work,
 there'd be no sense in supporting the extension without supporting
 OpenID and as such, has limited benefit in the wild for implementors.
 With OAuth, if we're able to get folks like AOL, Google, Yahoo and
 others to support it, the amount of effort necessary to support all of
 them becomes the same amount of work to support one.

 Anyway, I'm glad to see you on the OAuth list. Feel free to poke
 around; we're looking to put out a 0.9 Draft and have it implemented
 over the course of September in libraries and then release finally a
 1.0 Oct 1.

 Cheers,

 Chris

 On 8/27/07, David Fuelling [EMAIL PROTECTED] wrote:
  John,
 
  Have a look at OAuth
  (http://groups.google.com/group/oauth).  I think it's
  currently a private google group, but it seems like you've given a lot
 of
  thought to this type of thing, so I'm sure the group owners would
 welcome
  your input.  There's a lot of activity going on over there.
 
  David
 
 
  On 8/26/07, John Ehn [EMAIL PROTECTED] wrote:
  
   I have created a draft of a new specification that I think will help
 to
  fill a gap in OpenID functionality.
  
   What appears to be a newer productivity feature of many websites is
 the
  ability to import and utilize information from other sites.  For
 instance,
  Basecamp provides an API that allows other systems to access user data.
  This is a great feature, but it currently cannot be done with OpenID,
 due to
  the dependence on end-user interaction during the authentication
 process.
  
   The Trusted Authentication Extension provides for the ability for an
  OpenID Consumer to log in to another OpenID Consumer without user
  interaction.  The end user will be able to create a trusted connection
  between two OpenID enabled sites, which will allow a client site to
 access a
  destination site using the end user's Identity.
  
   Please provide your comments and feedback, as they are most
 appreciated.
  
   http://extremeswank.com/openid_trusted_auth.html
  
   Thank you,
  
   John Ehn
   [EMAIL PROTECTED]
  
   ___
   specs mailing list
   specs@openid.net
   http://openid.net/mailman/listinfo/specs
  
  
 
 
  ___
  specs mailing list
  specs@openid.net
  http://openid.net/mailman/listinfo/specs
 
 


 --
 Chris Messina
 Citizen Provocateur 
   Open Source Advocate-at-Large
 Work: http://citizenagency.com
 Blog: http://factoryjoe.com/blog
 Cell: 412 225-1051
 Skype: factoryjoe
 This email is:   [ ] bloggable[X] ask first   [ ] private

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


OpenID Trusted Authentication Extension

2007-08-26 Thread John Ehn
I have created a draft of a new specification that I think will help to fill
a gap in OpenID functionality.

What appears to be a newer productivity feature of many websites is the
ability to import and utilize information from other sites.  For instance,
Basecamp provides an API that allows other systems to access user data.
This is a great feature, but it currently cannot be done with OpenID, due to
the dependence on end-user interaction during the authentication process.

The Trusted Authentication Extension provides for the ability for an OpenID
Consumer to log in to another OpenID Consumer without user interaction.  The
end user will be able to create a trusted connection between two OpenID
enabled sites, which will allow a client site to access a destination site
using the end user's Identity.

Please provide your comments and feedback, as they are most appreciated.

http://extremeswank.com/openid_trusted_auth.html

Thank you,

John Ehn
[EMAIL PROTECTED]
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs