Re: Separation of Discovery from AuthN (was Proposal to form Discovery Working Group)

2009-01-06 Thread Nat Sakimura
But I suppose it is worthwhile to make the spec clearler.
It can be clearer by decomposeing the notion of OP into Discovery Service
and Authentication Service than collectively calling it as OP. That will
facilitate a better understanding of the strength and weakness of the
protocol as well.

=nat

2009/1/6 Drummond Reed drummond.r...@cordance.net

  Agreed that it makes sense to split it out when the underlying work (XRD
 1.0) is ready.



 =Drummond


   --

 *From:* David Recordon [mailto:drecor...@sixapart.com]
 *Sent:* Sunday, January 04, 2009 11:24 PM
 *To:* Drummond Reed
 *Cc:* sappe...@gmail.com; 'Nat Sakimura'; 'John Bradley'; specs@openid.net
 *Subject:* Re: Separation of Discovery from AuthN (was Proposal to form
 Discovery Working Group)



 I'd advocate for waiting until all of the discovery work occurring in
 OASIS, IETF, and W3C shakes out before we make changes to how OpenID
 discovery works.  I'd much rather make this sort of change once rather than
 twice.



 --David



 On Jan 4, 2009, at 11:14 PM, Drummond Reed wrote:



I'm just catching up on holiday mail and wanted to add another +1 to
 separation of Discovery from AuthN. The sooner the better…



 =Drummond


   --

 *From:* specs-boun...@openid.net 
 [mailto:specs-boun...@openid.netspecs-boun...@openid.net
 ] *On Behalf Of *David Fuelling
 *Sent:* Friday, December 26, 2008 8:47 AM
 *To:* Nat Sakimura
 *Cc:* John Bradley; specs@openid.net
 *Subject:* Re: Proposal to form Discovery Working Group



 On Thu, Dec 25, 2008 at 10:56 AM, Nat Sakimura n-sakim...@nri.co.jp
 wrote:

  2. Separation of OP into Discovery Service and Authentication Service.
  In the current terminology, OP spans both Discovery Service and
 Authentication Service.
  We should be explicit about it.


 +1.  I would like to see discovery services separated from OP services too.




 John Bradley wrote:
  Breno,
 
  I agree.  I recommended separating discovery into a separate doc for
  2.1.
 
  There didn't seem to be support for the idea at the time,  perhaps
  circumstances have changed and the idea will be accepted now.
 
  Regards
  John Bradley
  =jbradley



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



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




-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs


OpenID Authentication 2.0 Errata

2009-01-06 Thread Martin Atkins


Hi folks,

It seems that we don't currently have any central place to document the 
issues with OpenID Authentication 2.0, so I started a wiki page for it:


http://wiki.openid.net/OpenID-Authentication-2_0-Errata

Currently it only has one issue, which is the one that I encountered 
today that inspired me to do this.


The proposal to create Auth 2.1 mentioned that there are other errata 
that should be included in that spec, so adding those here ought to be 
useful.



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


Re: CLARIFICATION: Is OpenID Discovery Optional?

2009-01-06 Thread James Henstridge
2009/1/7 David Fuelling sappe...@gmail.com:
 All,

 Wondering if anybody, especially the original OIDF Board and any
 contributor's to the OpenID Auth 2.0 spec could comment on this question for
 me.

 Is OpenID Discovery, as seen in section 7.3 of the Auth spec, optional?
 More specifically, is the information returned by discovery meant to be
 Authoritative for a particular OpenID or OP Endpoint, or is it merely meant
 to be Informative.

This seems like a bit of a weird question to me.  The way the OpenID
is structured, I can easily write an OpenID server that will respond
with properly signed positive assertion responses for identity URLs
that I don't control, should an RP decide to talk to it.

This won't help me impersonate anyone to an RP though because the
discovery information doesn't point to my server.  Being the link from
the identity URL to the OpenID provider, I don't see how you could
treat it as anything other than authoritative.

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