Re: OPs to advertise support for OpenID extensions via the extension's type URI

2009-07-29 Thread David Recordon

Sounds good to me!

On Jul 22, 2009, at 5:23 PM, John Bradley wrote:


+1 I think that advertising the extension itself is a good practice.

A RP may prefer OPs that support the extension over ones that don't.

That is the case for PAPE now as an example.

With XRD most of that will be described in the OPs XRD rather than  
the users, but the same principal should apply.


John B.
On 22-Jul-09, at 12:00 PM, specs-requ...@openid.net wrote:


From: Breno de Medeiros br...@google.com
Subject: Re: OPs to advertise support for OpenID extensions via the
extension's type URI
To: Andrew Arnott andrewarn...@gmail.com
Cc: specs@openid.net
Message-ID:
29fb00360907221019t10a0393aydbae458ba8c66...@mail.gmail.com
Content-Type: multipart/alternative;
boundary=00151750e13a821afc046f4e91df

--00151750e13a821afc046f4e91df
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

I agree with Andrew on this suggestion. I don't think the UI WG  
proceeded

differently for any particular reason, except that no such convention
existed and we were not aware of side-effects previously.  
Regardless of
interoperability issues with existing libraries, I thinking having  
a type
URI for the extension is desirable from purely semantic standpoint  
(if a
human were to read such document, it would be more logically  
organized with

'umbrella' type URIs for the extension).


___
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: experimental namespace for openid.net

2009-07-10 Thread David Recordon
Should this experimental namespace only apply to work being done by  
OpenID working groups?  I'm very supportive of pushing the standards  
forward via prototypes, but that should be done as part of the OpenID  
community instead of by a single company.


I'd be very happy to help get a discovery working group spun up and  
charter them to modernize OpenID 2.0's discovery process.


--David

On Jul 10, 2009, at 11:58 AM, George Fletcher wrote:


+1 to http://experimental.openid.net

It would be good to add this to the repository work Breno and John  
are doing as having a registry for experimental URIs would be good  
as well.


Thanks,
George

Dirk Balfanz wrote:
[+gene...@openid.net mailto:gene...@openid.net for a broader  
audience]


On Thu, Jul 9, 2009 at 4:45 PM, Dirk Balfanz balf...@google.com mailto:balf...@google.com 
 wrote:


   Hi guys,
   Google would like to launch a feature in which we're allowing our
   Google Apps hosted domains to become OpenID providers. The
   authentication part of it is pretty simple - Google is already
   logging in users to their apps, so we can also host an OP endpoint
   for those domains and send assertions back to Relying Parties.
   What is more difficult is the discovery part. We have been working
   with the XRI TC to define a XRD-based discovery protocol that
   would allow this kind of hosting of discovery documents on behalf
   of our customers.
   We believe that providing proof-of-concept implementations drives
   standardization processes forward, so in this spirit we want to
   launch this feature in the near future, using a discovery protocol
   that as far as we can tell meets all the requirements of what the
   XRI TC is currently converging on, but which has not been vetted
   as an official standard (it's a chicken and egg thing - without
   PoC no standards, without standards by definition no
   standards-compliant implementations).

   While we were tossing around ideas http://markmail.org/message/ixc5led2lobdwij2 
in the

   standardization committees we just used random identifiers for new
   XML namespaces, etc. that we would need for this discovery
   protocol. Now that we're about to launch we need to decide what to
   call these things. We would like to use a namespace
   in http://specs.openid.net/... because we want this kind of
   discovery protocol to be part of OpenID, but we can't really use
   them because we don't have a next-generation discovery protocol  
yet.

   So what should we use? How
   about http://experimental.openid.net/... ? That way, Relying
   Parties know that what we're trying to do is be a part of the
   OpenID community and bring the protocol forward. On the other
   hand, this would also be a signal to the RP that they're using a
   feature that has not been vetted as a standard yet.
   For example, a discovery document for a domain balfanz.net
   http://balfanz.net at Google might look like this (notice the
   experimental namespace and the XML elements using it):

   ?xml version=1.0 encoding=UTF-8?
   xrds:XRDS xmlns:xrds=xri://$xrds xmlns=xri://$xrd*($v*2.0)
 ds:Signature xmlns:ds=http://www.w3.org/2000/09/xmldsig#;
 ds:SignedInfo
 ds:CanonicalizationMethod Algorithm=http://docs.oasis-open.org/xri/xrd/2009/01#canonicalize-raw-octets 
 /
 ds:SignatureMethod Algorithm=http://www.w3.org/2000/09/xmldsig#rsa-sha1 
 /

 /ds:SignedInfo
 ds:KeyInfo
 ds:X509Data
 ds:X509Certificate
 MIICgjCCA...
 /ds:X509Certificate
 ds:X509Certificate
 MIICsDCCAhmgAwIB...
 /ds:X509Certificate
 /ds:X509Data
 /ds:KeyInfo
 /ds:Signature
 XRD
 CanonicalIDbalfanz.net http://balfanz.net/CanonicalID
 Service priority=0
 Typehttp://specs.openid.net/auth/2.0/server/Type
 Typehttp://openid.net/srv/ax/1.0/Type
 Typehttp://specs.openid.net/extensions/pape/1.0/Type
 URIhttps://www.google.com/a/balfanz.net/o8/ud?be=o8/URI
 /Service
 Service priority=0 xmlns:experimental=http://experimental.openid.net/google/2009/07/xmlns/ 

 Typehttp://www.iana.org/assignments/relation/describedby/ 
Type

 MediaTypeapplication/xrds+xml/MediaType
 experimental:URITemplatehttps://www.google.com/accounts/o8/user-xrds?uri= 
{%uri}
   https://www.google.com/accounts/o8/user-xrds?uri=%7B%uri%7D/ 
experimental:URITemplate

 experimental:NextAuthorityhosted-id.google.com
   http://hosted-id.google.com/experimental:NextAuthority
 /Service
 /XRD
   /xrds:XRDS

   What do you guys think?

   Dirk.




___
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: Clarification needed in PAPE spec

2009-06-17 Thread David Recordon

Yeah, it was meant to be included with the value of an empty string.

--David

On Jun 17, 2009, at 10:56 AM, Andrew Arnott wrote:

A space-delimited list of no elements is the empty string.  So I'd  
say (and DNOA is coded such that) it cannot be omitted, but may be  
empty.

--
Andrew Arnott
I [may] not agree with what you have to say, but I'll defend to the  
death your right to say it. - S. G. Tallentyre



On Wed, Jun 17, 2009 at 10:07 AM, Allen Tom a...@yahoo-inc.com  
wrote:
Another ambiguous parameter is the  
openid.pape.preferred_auth_policies request parameter in section 5.1.


The first sentence in Section 5.1 says that all the request  
parameters are mandatory (MUST be included), however the  
description  openid.pape.preferred_auth_policies says that zero  
policies can be specified. Is there a special value for zero  
policy?  Or should the parameter be omitted if the no policy is  
requested?


http://openid.net/specs/openid-provider-authentication-policy-extension-1_0.html#anchor8

Thanks

Allen

___
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: OAuth Hybrid and UI ML?

2009-06-16 Thread David Recordon

Hey George,
Yes, they're open for reading but require a contribution agreement in  
order to post.  Mailman makes this a bit tricky since it means we need  
to moderate all new users so that you can receive emails but not post  
yourself.


--David

On Jun 16, 2009, at 5:00 AM, George Fletcher wrote:

Will these lists be open for reading to the community? I'd like to  
keep up with what's happening in both these groups.


Thanks,
George

David Recordon wrote:
Once the working groups are approved and someone is willing to  
moderate new members on the list to make sure they've signed  
contribution agreements before posting, I can make the list itself.


--David

On Jun 11, 2009, at 6:21 PM, Allen Tom wrote:


Hi Nat,

How does one create a mailing list? At least with regards to the  
OpenID UI WG, we're just mailing each other directly.


Allen



Nat Sakimura wrote:

Hi.
I just found out that the Mailing list for OAuth Hybrid WG and UI  
WG are not listed on http://openid.net/mailman/listinfo/ .  http://openid.net/mailman/listinfo/ 



To make sure equal participation, we should make it possible for  
people to find out about them.
Are they established at all? Where is the discussion being  
conducted right now?

--
Nat Sakimura (=nat)
http://www.sakimura.org/en/


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



___
specs mailing list
specs@openid.net mailto: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: OAuth Hybrid and UI ML?

2009-06-15 Thread David Recordon
Once the working groups are approved and someone is willing to  
moderate new members on the list to make sure they've signed  
contribution agreements before posting, I can make the list itself.


--David

On Jun 11, 2009, at 6:21 PM, Allen Tom wrote:


Hi Nat,

How does one create a mailing list? At least with regards to the  
OpenID UI WG, we're just mailing each other directly.


Allen



Nat Sakimura wrote:


Hi.

I just found out that the Mailing list for OAuth Hybrid WG and UI  
WG are not listed on http://openid.net/mailman/listinfo/ .


To make sure equal participation, we should make it possible for  
people to find out about them.


Are they established at all? Where is the discussion being  
conducted right now?


--
Nat Sakimura (=nat)
http://www.sakimura.org/en/

___
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: Requiring Pseudonymous Identifier

2009-05-13 Thread David Recordon
Agreed.  RP requests a pseudonymous identifier and it's up to the OP  
to figure out how to make one and ideally communicate back to the RP  
that it did so.


--David

On May 13, 2009, at 9:41 AM, Andrew Arnott wrote:

Agreed.  There is no reason for OpenID to mandate how pseudononymous  
identifiers are created.  That should be left up to the OP.


--
Andrew Arnott
I [may] not agree with what you have to say, but I'll defend to the  
death your right to say it. - Voltaire



On Wed, May 13, 2009 at 9:28 AM, George Fletcher gffle...@aol.com  
wrote:
I'm perfectly fine with using RP discovery as a mechanism for the RP  
to specify what policy it requires. I believe that unsolicited  
assertions are going to become more common, so we need to support it.


What I don't want OpenID to do is specify the actual syntax of the  
pseudonymous identifier. I agree that the RP has to trust the OP (in  
some sense) or make it's own determination that the OP is not  
honoring the RP's wishes and then take some action.


For RP's behind firewalls, it would be nice to allow them some  
mechanism other than RP discovery to assert their requirements, but  
that should preclude the discover option.


Thanks,
George

Andrew Arnott wrote:
leaves out the scenario of unsolicited assertions.A new directed  
identity value that the RP passes to the OP to indicate it wants a  
psuedononymous identifier.  Consider this:


An OP needs to perform RP discovery (already), and probably does so  
before sending an unsolicited assertion in order to find out what  
the assertion receiving URI would be for a given realm.  DNOA does  
this already.  If that RP's XRDS document included a TypeURI element  
that had a special psuedononymous-identifier-only-please value the  
OP could pick up on this, and send the unsolicited assertion using  
the appropriate type of claimed_id.


Likewise, when an RP sends an ordinary directed identity request to  
an OP, the OP would again notice the RP's XRDS during RP discovery  
and see what kind of identifier the RP wants and assert accordingly.


Yes, some OPs won't honor the RP's wishes, and some OPs don't do RP  
discovery at all.  Perhaps to help the RP detect whether the OP  
respected its wishes would be to send a PAPE extension or some other  
openid.* parameter to say yes, this is a pseudo- identifier.  RPs  
have no way to analytically be certain that some identifier is  
psuedononymous anyway, so ultimately the RP has to trust the OP  
(whether implicitly or through a white list is up to the RP).


--
Andrew Arnott
I [may] not agree with what you have to say, but I'll defend to the  
death your right to say it. - Voltaire



On Wed, May 13, 2009 at 8:44 AM, George Fletcher gffle...@aol.com mailto:gffle...@aol.com 
 wrote:


   I don't think OpenID should specify how pseudonymous identifiers
   are generated. That should be up to the OP. But I like the idea of
   using a fixed URI as the claimed_id value to specify the behavior
   desired by the RP. If, however, we need to grow this to cover
   anonymous based identifiers (i.e. the claims based models from
   earlier in this thread) then it might make sense to look at a PAPE
   extension that covers the type of identifier requested.

   Thanks,
   George


   Nat Sakimura wrote:

   Sorry for a slow response. This week is especially busy for  
me...


   I borrowed the notion from Austrian Citizen ID system.
   In there, the services are divided into sectors.
   A sector may span several agencies.
   They call ID as PIN (Personal Identification Number).

   There is a secret PIN (sPIN) which is not used anywhere but in
   their SmartCard.
   Then, sector sepcific PIN (ssPIN) is calculated in the manner  
of :


   SHA1(sPIN + SectorID)

   (Note, there is a bit more details but...)

   I have thrown OP secret into it.
   To avoid the analytic attack, I agree that it is better to use
   individual secret, as some of you
   points out.

   Regards,

   =nat

   On Tue, May 12, 2009 at 5:55 PM, Dick Hardt
   dick.ha...@gmail.com mailto:dick.ha...@gmail.com wrote:

   On 12-May-09, at 1:36 AM, Nat Sakimura wrote:

   Reason for using RP's Subject in XRD instead of simply
   using realm is
   to allow for something like group identifier.

   would you elaborate on the group identifier concept?


   This is just one idea. Downside of this approach
   is that we need to set up a WG.

   I am sure there are more ideas. It might be possible
   to utilize AX
   so that it will only be a profile that does not
   require a WG.

   So shall we start discussing which direction we want
   to go forward?

   sure!






   ___
   specs mailing list
   specs@openid.net mailto:specs@openid.net

   

Re: Requiring Pseudonymous Identifier

2009-05-13 Thread David Recordon
Does it make more sense to use a PAPE policy requesting a pseudonymous  
identifier or an AX attribute requesting one?  Any of these approaches  
would work, I just don't think we've mapped out the pros/cons of each.


--David

On May 13, 2009, at 8:44 AM, George Fletcher wrote:

I don't think OpenID should specify how pseudonymous identifiers are  
generated. That should be up to the OP. But I like the idea of using  
a fixed URI as the claimed_id value to specify the behavior desired  
by the RP. If, however, we need to grow this to cover anonymous  
based identifiers (i.e. the claims based models from earlier in this  
thread) then it might make sense to look at a PAPE extension that  
covers the type of identifier requested.


Thanks,
George

Nat Sakimura wrote:

Sorry for a slow response. This week is especially busy for me...

I borrowed the notion from Austrian Citizen ID system.
In there, the services are divided into sectors.
A sector may span several agencies.
They call ID as PIN (Personal Identification Number).

There is a secret PIN (sPIN) which is not used anywhere but in  
their SmartCard.

Then, sector sepcific PIN (ssPIN) is calculated in the manner of :

SHA1(sPIN + SectorID)

(Note, there is a bit more details but...)

I have thrown OP secret into it.
To avoid the analytic attack, I agree that it is better to use
individual secret, as some of you
points out.

Regards,

=nat

On Tue, May 12, 2009 at 5:55 PM, Dick Hardt dick.ha...@gmail.com  
wrote:



On 12-May-09, at 1:36 AM, Nat Sakimura wrote:

Reason for using RP's Subject in XRD instead of simply using  
realm is

to allow for something like group identifier.


would you elaborate on the group identifier concept?



This is just one idea. Downside of this approach
is that we need to set up a WG.

I am sure there are more ideas. It might be possible to utilize AX
so that it will only be a profile that does not require a WG.

So shall we start discussing which direction we want to go forward?


sure!








___
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: RECOMMENDED: Proposal to create the OpenID and OAuth Hybrid Extension working group

2009-01-31 Thread David Recordon
Unless there are any objections, I will change this voting period to match that 
of the CX working group where the vote will open Saturday February 14th. 

--David 

- David Recordon da...@sixapart.com wrote: 
 The Specifications Council recommends that the Foundation members approve the 
 creation of the OpenID and OAuth Hybrid Extension working group ( 
 http://openid.net/pipermail/specs-council/2009-January/99.html) , as 
 proposed below and found at 
 http://wiki.openid.net/OpenID-and-OAuth-Hybrid-Extension. 
 
 
If you are a member of the OpenID Foundation, you'll be able to login and vote 
on the creation of this new working group after this 14-day notice period. The 
vote thus will be from Wednesday February 11th through Wednesday February 18th. 
All votes are held in US Pacific Time. 

 
--David 

 

 

Background Information 
OpenID has always been focused on how to enable user-authentication within the 
browser. Over the last year, OAuth has been developed to allow authorization 
either from within a browser, desktop software, or mobile devices. Obviously 
there has been interest in using OpenID and OAuth together allowing a user to 
share their identity as well as grant a Relying Party access to an OAuth 
protected resource in a single step. A small group of people have been working 
on developing an extension to OpenID which makes this possible in a 
collaborative fashion within http://code.google.com/p/step2/. This small 
project includes a draft spec and Open Source implementations which the 
proposers would like to finalize within the OpenID Foundation. 

 
Working Group Name 
OpenID OAuth Hybrid Working Group 

 
Purpose 
Produce a standard OpenID extension to the OpenID Authentication protocol that 
provides a mechanism to embed an OAuth approval request into an OpenID 
authentication request to permit combined user approval. The extension 
addresses the use case where the OpenID Provider and OAuth Service Provider are 
the same service. To provide good user experience, it is important to present a 
combined authentication and authorization screen for the two protocols. 

 
Scope 
The proposed work is as follows: 

 
* Extend the OpenID authentication request/response and the assertion 
verification mechanism, to embed an OAuth approval request into an OpenID 
authentication request. Assuming the OpenID Provider and OAuth Service Provider 
are the same service. 
* Insulation of each protocol from the other, both for backwards compatibility 
as well as to enable OpenID and OAuth to evolve and incorporate additional 
features without requiring reviews of the combined usage. Especially, to allow 
future support for unregistered OAuth consumers. 
* Security analysis and best practices 

 
Out of scope 

 
* The OpenID extension does not define an unregistered OAuth consumers mode, 
but instead ensures that such support would be possible by protocol insulation. 
The unregistered consumers mode should be defined separately in the OAuth 
specifications. 

 
Anticipated Contributions 
Finalize the OpenID OAuth Extension spec 
(http://step2.googlecode.com/svn/spec/openid_oauth_extension/drafts/0/openid_oauth_extension.html)
 as an official OpenID Extension. 

 
Proposed List of Specifications 
OpenID OAuth Extension 1.0. Specification completion by Q1 2009. 

 
Anticipated audience or users of the work 
* OpenID Providers and Relying Parties 
* OAuth Consumers and Service Providers 
* Implementers of OpenID Providers and Relying Parties 

 
Language in which the WG will conduct business 
English. 

 
Method of work 
E-mail discussions on the working group mailing list and working group 
conference calls. 

 
Basis for determining when the work of the WG is completed 
The work will be completed once it is apparent that maximal consensus on the 
protocol proposal has been achieved within the working group, consistent with 
the purpose and scope. 

 
Proposers 
* Ben Laurie, b...@google.com, Google 
* Breno de Medeiros, br...@google.com, Google 
* David Recordon, drecor...@sixapart.com, Six Apart 
* Dirk Balfanz, balf...@google.com, Google 
* Joseph Smarr, jsm...@plaxo.com, Plaxo 
* Yariv Adan, ya...@google.com, Google 
* Allen Tom, a...@yahoo-inc.com , Yahoo 
* Josh Hoyt, j...@janrain.com , JanRain 

 
Initial Editors 
* Dirk Balfanz, balf...@google.com, Google 
* Breno de Medeiros, br...@google.com, Google 
 
 ___ 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: RECOMMENDED: Proposal to create the Contract Exchange Extension working group

2009-01-31 Thread David Recordon
And the proposal...

(i) WG name
Contract Exchange Extension Working Group

(ii) Purpose
The purpose of this WG is to produce a standard OpenID extension to
the OpenID Authentication protocol that enables arbitrary parties to
create and exchange a mutually-digitally-signed contract. This
contract can be both broadband and mobile friendly through appropriate
bindings that will be defined for each use case.

(iii) Scope
Development of a specification that allows parties to exchange a
mutually-digitally-signed contract leveraging on OpenID Authentication
2.0 and OpenID Attribute Exchange 2.0 via the appropriate bindings
defined in the specification.

Out of scope

   * UI and user experience: The Working Group will develop the wire
protocol and and any related processing mechanisms required to support
it but user interface and experience is out of scope.
   * Public Key Discovery method: This functionality will be either
defined in the XRD 1.0 specification currently in progress at the
OASIS XRI TC or a mechanism that works with OpenID Authentication
2.0/2.1 discovery will be defined independently.
   * Terms negotiation: Actual negotiation of the terms of a contract
should be dealt with out-of-band or by other specifications.
   * Assurance: These will be handled by third-party assurance
programs or other identity governance frameworks.
   * Trust hierarchies. It is the intent that this specification be
usable by any trust community, whether it uses conventional PKI
hierarchies, peer-to-peer trust mechanisms, reputation systems, or
other forms of trust assurance. The specification of any particular
trust root, trust hierarchy, or trust policy is explicitly out of
scope.

(iv) Proposed List of Specifications
   * Contract Exchange 1.0 - Expected completion of the first
iteration is in Q1 2009.

(v) Anticipated audience or users of the work
Implementers of OpenID Providers and Relying Parties, especially those
who require security and accountability features to exchange sensitive
customer information (e.g. personally identifiable information and
credit card numbers) responsibly among trusted parties.

(vi) Language in which the WG will conduct business
English.

(vii) Method of work
E-mail discussions on the working group mailing list, working group
conference calls, and possibly face-to-face meetings at conferences.

(viii) Basis for determining when the work of the WG is completed
Drafts will be evaluated on the basis of whether they increase or
decrease consensus within the working group. The work will be
completed once it is apparent that maximal consensus on the drafts has
been achieved, consistent with the purpose and scope.

(b) Background Information.
(i) Related work being done by other WGs or organizations
   * OpenID Authentication 2.1 [AN]
   * OpenID Attribute Exchange Extension 2.0 [AX]
   * LIberty Alliance Identity Governance Framework [IGF] 1.0 Draft
   * XML Advanced Electronic Signatures [XAdES]
   * WS-Trust 1.3 [WS-trust]
   * XRI 2.0 and XRI 3.0 [XRI]
   * XRD 1.0 [XRI]
   * XDI 1.0 [XDI]
   * Vendor Relationship Management [VRM]

(ii) Proposers
   * Drummond Reed, =drummond, drummond.r...@parity.com,
Cordance/Parity/OASIS (U.S.A)
   * Henrik Biering, h...@netamia.com, Netamia (Denmark)
   * Hideki Nara, hd...@ic-tact.co.jp, Tact Communications (Japan)
   * John Bradeley, jbrad...@mac.com, OASIS IDTrust Member Section (Canada)
   * Mike Graves, mgra...@janrain.com, JanRain, Inc. (U.S.A.)
   * Nat Sakimura, n-sakim...@nri.co.jp, Nomura Research Institute, Ltd.(Japan)
   * Robert Ott, robert@clavid.com, Clavid (Switzerland)
   * Tatsuki Sakushima, tats...@nri.com, NRI America, Inc. (U.S.A.)
   * Toru Yamaguchi, try...@gmail.com, DeNA Co. Ltd.  (Japan)

Editors:
Nat Sakimura, n-sakim...@nri.co.jp, Nomura Research Institute, Ltd.

(iii) Anticipated Contributions
   * Sakimura, N., et. al OpenID Trusted data eXchange Extention
Specification (draft), Oct. 2008. [TX2008].

- David Recordon da...@sixapart.com wrote:

 The Specifications Council recommends that the Foundation members
 approve the creation of the Contract Exchange Extension working group
 (http://openid.net/pipermail/specs-council/2009-January/000110.html),
 as proposed below and found at
 http://wiki.openid.net/Working_Groups%3AContract_Exchange_1.
 
 If you are a member of the OpenID Foundation, you'll be able to login
 and vote on the creation of this new working group after this 14-day
 notice period.  The vote thus will be from Wednesday Saturday 14th
 through Saturday February 21st.  All votes are held in US Pacific
 Time.
 
 --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


Re: Request for consideration of AX 2.0 Working Group Charter Proposal

2009-01-24 Thread David Recordon
This has been on my list to kick to the specs council but I've also been 
waiting for Dick to reengage since he's been such a core driver of the AX spec 
in the past. :) 

--David 

- Nat Sakimura sakim...@gmail.com wrote: 
 
 
 
 On Sat, Jan 24, 2009 at 4:02 AM, Breno de Medeiros  br...@google.com  
 wrote: 
 

Unfortunately, not much to report except that most appear to agree in 
 your last suggestion, which I parse as: 
 
 Allow type.alias = type_schema_url to define a 'type namespace'. 
 Within that namespace it would then be possible to create an 
 extensible schema based on plain string key-value pairs. 
 
 We need to: 
 
 1. Get the blessing of specs council to form a WG. I believe we have 
 addressed all concerns raised in threads in the Wiki proposal and I am 
 not sure why I have not heard from specs council back. How do we call 
 for a vote on the WG formation? 

 Right. I will kick the specs council for this one also. 
 The board is aware that specs council has not been effective and 
 starting to fix it. (There will be a board voting to start the ammendment 
 to the OpenID process shortly.) 
 
 Guys, please raise your voices also from the community side. 
 
 Dick, I think you still are a spec council member, so please start 
 pinging other specs council members from inside. 
 
 Process-wise, there are four more steps involved in startgin this WG. 
 
 1) Specs council's recommendation 
 2) Membership vote to form WG. 
 3) Contributors submitting IPR agreements for this WG. 
 4) OIDF to provide the post restricted ML and SVN repository for the WG. 
 
 Additionally, it would be good if OIDF could supply write controlled 
 wiki just like OASIS Open does. 
 
 
 


 
 2. Start writing this spec, in particular hash out the parts that are 
 in agreement so that people can start cranking on this. :) 

 Yes! 
 
 


 


 
 
 
 On Fri, Jan 23, 2009 at 10:54 AM, Dick Hardt  dick.ha...@gmail.com  wrote: 
  Hey Everyone 
  I dropped off the planet for a bit moving and getting my world setup. Have 
  missed all the email threads on this. 
  What have I missed out on? :-) 
  I plan on participating heavy in the AX 2.0 spec myself. 
  -- Dick 
  
  On Tue, Dec 23, 2008 at 12:12 PM, Allen Tom  a...@yahoo-inc.com  wrote: 
  
  I believe that one of the goals of AX 2.0 should be to maintain 
  backwards compatible with AX 1.0 whenever possible. 
  
  Allen 
  
  
  Mike Jones wrote: 
   Can you add a clear statement to the draft charter that implementations 
   already using AX 1.0 will remain compatible with the output of this 
   working 
   group? Or is backwards-compatibility with existing AX implementations 
   not a 
   goal of this work? 
   
   -- Mike 
   
   -Original Message- 
   From: specs-boun...@openid.net [mailto: specs-boun...@openid.net ] On 
   Behalf Of Breno de Medeiros 
   Sent: Thursday, December 18, 2008 6:18 PM 
   To: OpenID Specs Mailing List 
   Cc: d...@skip.com ; hd...@ic-tact.co.jp ; mgra...@janrain.com 
   Subject: Request for consideration of Working Group Charter Proposal 
   
   I would like to submit the following proposal for a new Working Group 
   charter to your consideration, following the OpenID IPR process: 
   
   The proposal charter is also available at: 
   http://wiki.openid.net/Working_Groups:AX_2.0 
   
   OpenID Attribute Exchange 2.0 Working Group (AX 2.0) 
   
   
   Charter Proposal 
   
   In accordance with the OpenID Foundation IPR policies and procedures 
   this note proposes the formation of a new working group chartered to 
   produce an OpenID specification. As per Section 4.1 of the Policies, 
   the proposed charter is below (still liable to change during this 
   feedback period). 
   
   
   I. Name 
   
   Attribute Exchange Extension Working Group (AX) 
   
   
   II. Statement of Purpose 
   
   Produce an updated version of the Attribute Exchange Extension. 
   
   
   III. Scope 
   
   Update the Attribute Exchange Extension to include support for 
   identified needs. Currently identified needs: 
   
   * Provide mechanisms for RP to require, and the OP to assert, 
   claims about the quality of the attributes. 
   * Create an extensible registry of claim types, such as 
   axschema.org for attribute types. The registry should also provide 
   non-normative guidance on how claims can be validated, which will 
   depend on the nature of attribute type as well as claim type. 
   * Introduce a new request/response mode which, unlike fetch and 
   store, allows for both transmittal of some values and request of 
   others. The transmittal not necessarily has the significance of a 
   store request (could be informative, or for requesting validation). 
   * Introduce a direct communication method in both directions 
   (OP-RP), supported via discovery, for bulk exchange of attributes 
   about (potentially) multiple users. 
   
   
   IV. Specifications 
   
   OpenID Attribute Exchange 2.0 
   
   
   V. Anticipated audience 
   
   

Re: OpenID Problem

2009-01-14 Thread David Recordon
Hi Faisal, 
While this is most likely a permissions issue between PHP and your filesystem, 
I doubt that you'll receive an answer on this mailing list. The 
specs@openid.net mailing list is designed to discuss the OpenID specifications 
themselves. You can try reposting to gene...@openid.net though might have more 
luck on the d...@lists.openidenabled.com mailing list which you can find at 
http://lists.openidenabled.com/mailman/listinfo/dev. 

--David 

- Faisal Rehman faisalrehma...@yahoo.com wrote: 
 
Hi, 

I have download openid library from here 
http://www.openidenabled.com/php-openid/ 
 
 and i am facing problem how to use the given example. The Error i am facing 
 is 
 
 Could not create the FileStore directory '/tmp'. Please check the effective 
 permissions. 
 
 Even in my ini.php the value of open_basedir 
 
 /var/www/vhosts/super-phone.com/httpdocs:/tmp:/tftpboot 
 
 and master value for this is set as no value. 
 
 tmp folder is in httpdocs have permission 777 but this is still giving this 
 error i dont know why. 

and i am setting $store_path = /tmp in common.php 
 
 please helpme i will be very thankfull to you. 
 
 ___ 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: Separation of Discovery from AuthN (was Proposal to form Discovery Working Group)

2009-01-04 Thread David Recordon
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.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


Re: [OIDFSC] FW: Proposal to create the TX working group

2008-12-31 Thread David Recordon
...@ic-tact.co.jp, Tact Communications (Japan)
- John Bradeley, jbrad...@mac.com, OASIS IDTrust Member Section
(Canada)
- Mike Graves, mgra...@janrain.com, JanRain, Inc. (U.S.A.)
- Nat Sakimura, n-sakim...@nri.co.jp, Nomura Research Institute,
Ltd.(Japan)
- Robert Ott, robert@clavid.com, Clavid (Switzerland)
- Tatsuki Sakushima, tats...@nri.com, NRI America, Inc. (U.S.A.)
- Toru Yamaguchi, try...@gmail.com, Cybozu Labs (Japan)

 In short, my first reaction to reading your email was to think, Wow, here
 it is, the first example of OpenID turning into W3C and IETF and every other
 standards organization that turns into a small group of insiders trying to
 control innovation!



 Of course I think you, more than almost anyone, can appreciate the irony of
 that thought �C I believe it was to avoid that very situation that the OIDF
 was created, no?



 So if we DON'T want that to happen, I think what we need to do ASAP is turn
 this into a constructive dialog between the proposers of this Working Group
 and the Specs Council about how the charter might be amended to addess some
 of your concerns. (I'm not commenting yet on your specific concerns, other
 than to say that I agree with some and not with others.)



 I suspect email is going to be much too slow for such a dialog, so I would
 suggest that Nat and Tatksuki set up a telecon between the Working Group
 proposers and the Specs Council members. I would also suggest that before
 such a telecon, the Specs Council get together and collectively list their
 issues with the Charter on the Working Group Charter page. I have added a
 section for this purpose:




 http://wiki.openid.net/Working_Groups%3AContract_Exchange_1#cSpecificationCouncilIssues



 It may be that all the Specs Council members agree with your four points
 below, in which case you can just wholesale copy them into the wiki page.
 However it is very important that the Specs Council come to it's own
 consensus about the issues it has with the charter, because without that,
 the WG proposers have no hope of addressing these issues, either with
 counterarguments or with potential amendments.



 Listing the issues there also enables us to have a more focused discussion
 than email alone by using comments directly on the wiki page.



 =Drummond


   --

 *From:* David Recordon [mailto:record...@gmail.com]
 *Sent:* Wednesday, December 31, 2008 12:33 AM
 *To:* Nat Sakimura
 *Cc:* specs-coun...@openid.net; Josh Hoyt; Tatsuki Sakushima; John
 Bradley; hd...@ic-tact.co.jp; Robert Ott; Michael Graves; Henrik Biering;
 Drummond Reed; Nat Sakimura; 山口��

 *Subject:* Re: [OIDFSC] FW: Proposal to create the TX working group



 Hi Nat,

 I read Josh's email as agreeing with Mike's statement of:

 The OpenID Specifications Council recommends that members reject this
 proposal to create a working group because the charter is excessively broad,
 it seems to propose the creation of new mechanisms that unnecessarily create
 new ways to do accomplish existing tasks, such as digital signatures, and it
 the proposal is not sufficiently clear on whether it builds upon existing
 mechanisms such as AX 1.0 in a compatible manner, or whether it requires
 breaking changes to these underlying protocols.


 While you have clarified that you don't intend to create a new XML
 signature mechanism, OAuth describes a mechanism to use public keys to sign
 these sorts of parameters.  Signatures aside, as Mike said other aspects of
 the charter seem quite broad and it is unclear how it will build upon AX 1.0
 and other underlying existing OpenID technologies.

 Given the draft charter at
 http://wiki.openid.net/Working_Groups%3AContract_Exchange_1:
 1) The purpose of producing a series of extensions seems too broad.  OpenID
 was born on the idea of doing one simple thing and we've seen success with
 OpenID and related technologies when they are made up of small pieces
 loosely joined.  OpenID Authentication 2.0 broke this rule in some areas and
 we're now seeing the repercussions of doing so.

 2) In what jurisdictions are these contracts legally binding?  Is
 arbitrary parties to create and exchange a mutually-digitally-signed
 legally binding 'contract' a justifiable statement or should it be toned
 down?  It should also be kept in mind that since OpenID's creation it has
 been very clear that OpenID does not provide trust, but rather trust can be
 built on top of identity.  I'm not saying that OpenID should never deal with
 trust, just trying to understand if this Working Group intends to change how
 OpenID currently does not create this form of trust.

 3) The purpose says that the Working Group intends to possibly extend AX
 and create a series of specifications.  It does not seem prudent to give a
 Working Group the ability to arbitrarily extend an existing extension or
 create an unlimited number of specifications.

 4) The Scope section is still not clear

Re: Proposal to form Discovery Working Group

2008-12-22 Thread David Recordon
Agreed with Breno here.  We're going to have to make a change to  
OpenID discovery at some point over the next year as other groups  
finish their evolutions of Yadis, XRDS, etc.  I like this being a  
separate WG since it means that the core Auth spec can choose to move  
to using it at a later date versus being tied up on it's development.

--David

On Dec 20, 2008, at 12:48 AM, Breno de Medeiros wrote:

 It is part of the scope of this group to develop a best-practices
 guidance for transition from YADIS to XRD discovery.

 Full backward-compatibility is not a goal, since at least one new
 mechanism for publishing discovery information is expected to make
 part of XRD discovery (dynamic mapping type), and this new mechanism
 is being put there (in XRD discovery) in large part because the
 current YADIS mechanism makes it difficult for smaller sites to become
 OPs/RPs by using a hosted solution (so it is an OpenID-driven need for
 wider adoption).

 XRD discovery is also expected to include a signing mechanism, which
 will allow for use of higher-security discovery profiles.  As part
 of this best-practices document, the OpenID discovery spec should give
 guidance on the security characteristics of each profile. The current
 mechanism (which limits re-directs and enforces realm authority =
 return_to url authority) will constitute a profile and there will
 likely be at least a second profile that verifies signatures on the
 discovered documents but allow for unmatched realm/return_to URLs.

 That being said, we are certainly aware of the need to make the
 transition as smooth as possible, and that is why it is part of the
 scope of this group to write a transitions guidance document.


 On Fri, Dec 19, 2008 at 11:28 PM, Mike Jones
 michael.jo...@microsoft.com wrote:
 Can you add a clear statement to the draft charter that  
 implementations already using Yadis will remain compatible with the  
 output of this working group, since, as I understand it, XRDS- 
 Simple is intended to be compatible with Yadis?  Or is backwards- 
 compatibility with existing OpenID 2.0 implementations not a goal  
 of this work?

   -- Mike

 -Original Message-
 From: specs-boun...@openid.net [mailto:specs-boun...@openid.net] On  
 Behalf Of Breno de Medeiros
 Sent: Thursday, December 18, 2008 6:14 PM
 To: OpenID Specs Mailing List
 Cc: David Recordon; Brian Eaton; Johannes Ernst
 Subject: Proposal to form Working Group

 I would like to submit the following proposal for a working group
 charter (also available at
 http://wiki.openid.net/Working_Groups:Discovery):

 Services and Metadata Discovery Coordination Working Group  
 (Discovery)

 Charter Proposal

 In accordance with the OpenID Foundation IPR policies and procedures
 this note proposes the formation of a new working group chartered to
 produce an OpenID specification. As per Section 4.1 of the Policies,
 the proposed charter is below (still liable to change during this
 feedback period).


 I. Name

 Services and Metadata Discovery Coordination Working Group  
 (Discovery)


 II. Statement of Purpose

 Produce a document describing the OpenID discovery workflow, updating
 the current mechanism to describe how to use OASIS specifications for
 discovery, to be drafted by the OASIS XRI TC. The intention is that
 the document will be incorporated as part of some future version of
 the OpenID Authentication spec.


 III. Scope

 Produce a document describing the use of OASIS discovery
 specifications as formulated by the OASIS XRI TC, for normative
 application by all other OpenID specifications. Produce a document
 describing the recommended migration of services discovery from the
 Yadis 1.0 specification to the discovery specifications currently
 being developed by the OASIS XRI TC. All types of identifiers
 addressed by OASIS XRI TC discovery (XRD 1.0) are within scope of  
 this
 WG. Publish a list of service and resource types supported by the
 discovery mechanism.


 IV. Specifications

 OpenID Discovery, including a sub-spec for Trusted OpenID Discovery,
 and a best-practices guidance document for migration.


 V. Anticipated audience

 All those interested in the OpenID specifications.


 VI. Language of business

 English.


 VII. Method of work

 Mailing list discussion. Posting of intermediate drafts in the OpenID
 Wiki. Virtual conferencing on an ad-hoc basis.


 VIII. Basis for completion of the activity

 The discovery document is final and all deliverables have been
 incorporated into the OpenID Authentication spec, perhaps by
 reference.


 Background Information


 I. Related Work

 XRD 1.0 spec, being drafted by the OASIS XRI TC.


 II. Initial Membership

   * Brian Eaton, bea...@google.com, Google, Inc.
   * Johannes Ernst, jer...@netmesh.us, NetMesh. (editor)
   * Eran Hammer-Lahav, e...@hueniverse.com, Yahoo! Inc.
   * Breno de Medeiros, br...@google.com, Google, Inc. (editor)
   * David Recordon, da

Re: Proposal to form Discovery Working Group

2008-12-22 Thread David Recordon
Can you please put it on 
http://wiki.openid.net/Working_Groups%3AOpenID_Discovery?

Thanks,
--David

On Dec 22, 2008, at 11:08 AM, Breno de Medeiros wrote:

 BTW, the discovery WG proposal does not appear in the new version of  
 the wiki.

 On Mon, Dec 22, 2008 at 11:07 AM, Breno de Medeiros  
 br...@google.com wrote:
 For the time being, I would be happy if the 2.1 spec moved all the
 references to discovery to a second document.

 The first version of the separate document would just clone the
 current approach to discovery in the 2.0 spec. If the updated version
 that explains XRD discovery is available before the 2.1 WG completes
 its work, then it could refer to the new document, otherwise it could
 refer to the old document. In the case of pointing to old document,  
 we
 probably should add an appendix noting that changes in discovery to
 support new use cases are coming, and pointers on how to manage the
 transition.



 On Mon, Dec 22, 2008 at 10:27 AM, David Recordon drecor...@sixapart.com 
  wrote:
 Agreed with Breno here.  We're going to have to make a change to  
 OpenID
 discovery at some point over the next year as other groups finish  
 their
 evolutions of Yadis, XRDS, etc.  I like this being a separate WG  
 since it
 means that the core Auth spec can choose to move to using it at a  
 later date
 versus being tied up on it's development.

 --David

 On Dec 20, 2008, at 12:48 AM, Breno de Medeiros wrote:

 It is part of the scope of this group to develop a best-practices
 guidance for transition from YADIS to XRD discovery.

 Full backward-compatibility is not a goal, since at least one new
 mechanism for publishing discovery information is expected to make
 part of XRD discovery (dynamic mapping type), and this new  
 mechanism
 is being put there (in XRD discovery) in large part because the
 current YADIS mechanism makes it difficult for smaller sites to  
 become
 OPs/RPs by using a hosted solution (so it is an OpenID-driven  
 need for
 wider adoption).

 XRD discovery is also expected to include a signing mechanism,  
 which
 will allow for use of higher-security discovery profiles.  As  
 part
 of this best-practices document, the OpenID discovery spec should  
 give
 guidance on the security characteristics of each profile. The  
 current
 mechanism (which limits re-directs and enforces realm authority =
 return_to url authority) will constitute a profile and there will
 likely be at least a second profile that verifies signatures on the
 discovered documents but allow for unmatched realm/return_to URLs.

 That being said, we are certainly aware of the need to make the
 transition as smooth as possible, and that is why it is part of the
 scope of this group to write a transitions guidance document.


 On Fri, Dec 19, 2008 at 11:28 PM, Mike Jones
 michael.jo...@microsoft.com wrote:

 Can you add a clear statement to the draft charter that  
 implementations
 already using Yadis will remain compatible with the output of  
 this working
 group, since, as I understand it, XRDS-Simple is intended to be  
 compatible
 with Yadis?  Or is backwards-compatibility with existing OpenID  
 2.0
 implementations not a goal of this work?

 -- Mike

 -Original Message-
 From: specs-boun...@openid.net [mailto:specs-boun...@openid.net]  
 On
 Behalf Of Breno de Medeiros
 Sent: Thursday, December 18, 2008 6:14 PM
 To: OpenID Specs Mailing List
 Cc: David Recordon; Brian Eaton; Johannes Ernst
 Subject: Proposal to form Working Group

 I would like to submit the following proposal for a working group
 charter (also available at
 http://wiki.openid.net/Working_Groups:Discovery):

 Services and Metadata Discovery Coordination Working Group  
 (Discovery)

 Charter Proposal

 In accordance with the OpenID Foundation IPR policies and  
 procedures
 this note proposes the formation of a new working group  
 chartered to
 produce an OpenID specification. As per Section 4.1 of the  
 Policies,
 the proposed charter is below (still liable to change during this
 feedback period).


 I. Name

 Services and Metadata Discovery Coordination Working Group  
 (Discovery)


 II. Statement of Purpose

 Produce a document describing the OpenID discovery workflow,  
 updating
 the current mechanism to describe how to use OASIS  
 specifications for
 discovery, to be drafted by the OASIS XRI TC. The intention is  
 that
 the document will be incorporated as part of some future version  
 of
 the OpenID Authentication spec.


 III. Scope

 Produce a document describing the use of OASIS discovery
 specifications as formulated by the OASIS XRI TC, for normative
 application by all other OpenID specifications. Produce a document
 describing the recommended migration of services discovery from  
 the
 Yadis 1.0 specification to the discovery specifications currently
 being developed by the OASIS XRI TC. All types of identifiers
 addressed by OASIS XRI TC discovery (XRD 1.0) are within

A Working Groups Wiki Page

2008-12-03 Thread David Recordon
We now have a wiki page for Working Groups!  
http://wiki.openid.net/Working_Groups

I've listed the current PAPE WG as well as the groups that I know have  
been proposed.  I've also filled in the draft charter for the Auth 2.1  
group at http://wiki.openid.net/Working_Groups:Auth_2.1.

If you're wanting to see a WG happen, please take this time to fill in  
it's draft charter so that members of this list can review it.  My  
goal would be to have all four of the proposed groups ready to be  
voted on by the Foundation Membership during the same period as the  
Board election -- one week from today -- so that they can all be  
created within the next two weeks.

If you need help writing a charter, I'm happy to help.

--David

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


Re: Proposal to create the TX working group

2008-12-03 Thread David Recordon
)  Related work being done by other WGs or organizations:

OpenID Attribute Exchange Extension 1.0 [AX]
LIberty Alliance Identity Governance Framework [IGF] 1.0 Draft
XML Advanced Electronic Signatures [XAdES]
WS-Trust 1.3 [WS-trust]
XRI 2.0 [XRI]
XDI 1.0 [XDI]
Vendor Relationship Management [VRM]

 (ii)  Proposers:

   Drummond Reed, [EMAIL PROTECTED], Cordance/Parity/OASIS  
(U.S.A)

   Henrik Biering, [EMAIL PROTECTED], Netamia (Denmark)
   Hideki Nara, [EMAIL PROTECTED], Tact Communications (Japan)
   John Bradeley, [EMAIL PROTECTED], OASIS IDTrust Member Section  
(Canada)

   Mike Graves, [EMAIL PROTECTED], JanRain, Inc. (U.S.A.)
   Nat Sakimura, [EMAIL PROTECTED], Nomura Research Institute,  
Ltd.(Japan)

   Robert Ott, [EMAIL PROTECTED], Clavid (Switzerland)
   Tatsuki Sakushima, [EMAIL PROTECTED], NRI America, Ltd. (U.S.A.)
   Toru Yamaguchi, [EMAIL PROTECTED], Cybozu Lab (Japan)


   Editors:

   Nat Sakimura, [EMAIL PROTECTED], Nomura Research Institute, Ltd.

 (iii)  Anticipated Contributions:
* Sakimura, N., et. al OpenID Trusted data eXchange Extention  
Specification (draft), Oct. 2008. [TX2008].







On Wed, Nov 12, 2008 at 6:39 AM, David Recordon [EMAIL PROTECTED] 
 wrote:
Just wanted to add that Nat is running a session on TX at IIW this  
afternoon.  We should definitly chat about the needs being expressed  
in this thread and how they might be able to be solved with OpenID.


--David


On Nov 11, 2008, at 1:13 PM, Martin Paljak wrote:

On 09.11.2008, at 20:51, Nat Sakimura wrote:
As to AX+SAML (or for that matter XAdES) is concerned, that is a  
valid approach, but if I were to use SAML, I would use


Just to clarify a technical detail: The XAdES example regarding  
Estonia you mentioned earlier does not include transporting XAdES  
payloads over OpenID AX (which seems to be the purpose of the  
discussed workgroup where the similarities of SAML over AX come in).  
The special behavior and out of band assurances given by openid.ee  
does not include anything new on the protocol level, just added  
semantics to basic OpenID transactions. If we could use PDF  
signatures as legally valid signatures in Estonia, it could be PDF  
based signatures instead of XAdES, or ODF signatures, or MS .doc  
signatures.


FYI, openid.ee allows a RP to upload a contract (template) which  
must be agreed with and digitally signed (legally binding signature  
resulting in an XAdES document with the filled in contract signed by  
the user with an ID-card and stored on the OP) before the OP starts  
issuing positive assertions about the given user to the given RP.  
The contract could be a document of any kind (PDF, JPG, DOC, TXT)  
and the only thing that is transferred to the RP over AX is a  
'secret url' from where the RP can download the signed contract  
(XAdES container with the possibly PDF contract in it).


The actual assurance (that the user has signed the contract the RP  
has uploaded) comes from out of band agreements/contracts between OP  
and RP. The AX attribute is just an extra option, if the RP wishes  
to automatically fetch and store the signed contract somewhere.


Basically it is an advanced and legally binding 'I agree with terms  
and conditions' checkbox built on top of standard OpenID.
With legally binding I mean that it is dead simple in the court:  
Here are the terms and conditions you digitally signed and which  
you have violated as checking checkboxes and pressing 'continue' is  
not a legally binding action in Estonia, at least I don't know of  
any court cases about it.


If you need an example use case, think of signing and faxing NDA-s  
before you can download some simple secret product documentation.



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






--
Nat Sakimura (=nat)
http://www.sakimura.org/en/



--
Nat Sakimura (=nat)
http://www.sakimura.org/en/


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


Re: Completing the SREG 1.1 specification

2008-11-29 Thread David Recordon
I certainly want to see us push the world to implementing AX instead  
of SREG, though agree with Mart that there are existing  
interoperability problems with SREG that would be nice to fix given  
that large OPs are still implementing it in a broken fashion.  I'd see  
no issue with including in the SREG spec that people really should go  
use AX instead.

--David

On Nov 29, 2008, at 12:40 AM, Dick Hardt wrote:


 On 28-Nov-08, at 11:28 PM, Martin Atkins wrote:


 I agree that it's not ideal to have both, and in an ideal world
 everyone
 would use AX, but currently SREG seems to be more widely deployed  
 than
 AX. This working group proposal was motivated not by some desire to
 needlessly perpetuate SREG but rather by actual real-world interop
 problems I've had to deal with as an implementer.

 As long as folks still want to implement SREG, I think it's  
 beneficial
 to have a specification that actually works in practice, which the
 current draft does not.

 Agreed. I was checking to see what people want to implement!

 If the community is ready to move to AX, then you don't need to do the
 work.

 If the community wants both, then it does need to get cleaned up.


 Dick Hardt wrote:
 A related topic.

 Wondering what the community thinks of having two specifications for
 moving around profile data: we have SREG and AX: do we need both?

 ___
 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: PAPE and NIST level policies.

2008-11-25 Thread David Recordon
Yeah, the latest draft is at 
http://openid.net/specs/openid-provider-authentication-policy-extension-1_0-05.html
 
.

On Nov 25, 2008, at 2:21 AM, Martin Paljak wrote:

 Right. I was lazy and google directed me to 1.0-02 as the first
 response ...

 m.
 On 25.11.2008, at 12:03, Nat wrote:

 The proposal on the table has generalized NIST thing, I believe.

 As to the upstream hint is concerned, I think it is a good idea but
 it was out of scope of the current WG. It belongs to the future spec
 I guess.

 [EMAIL PROTECTED] via iPhone

 On 2008/11/25, at 18:10, Martin Paljak [EMAIL PROTECTED] wrote:

 Hi.

 PAPE responses have the ability to send NIST levels used for
 authentication. It would be useful to add these levels as
 standardized
 request policy URLs to the spec so that the RP could send hints on
 wished authentication strength to the OP.

 BTW, why is there a specific nist_auth_level parameter which is
 directly tied to one standards institute yet the 'core' of PAPE,
 policies, don't really define anything except vague 'policies to be
 specified elsewhere' ?


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




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

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




 ___
 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: Proposing an OpenID Authentication 2.1 Working Group

2008-11-11 Thread David Recordon
Yep, thanks!  I'll be sending out a new charter shortly.

On Nov 11, 2008, at 11:24 AM, George Fletcher wrote:

 Great notes! Thanks!

 Martin Atkins wrote:
 Here's the output from today's IIW session on this:


 2.0 has been finalized
 bunch of implementations
 found lots of spec bugs

 also gone and done oauth and email addresses and other things. Can we
 support these in the core spec?

 - Making the spec more readable and fixing bugs (eratta)
   - Delegation
   - Error handling
 - Adding a security appendix
   - could be a separate document referred to by the spec
   - possibly produced by separate group
   - Who controls this security page?
 - Security committee could look after this.
 - or Allen at Yahoo! will be editing a security document
 - Clarifying XRI
   - Currently there's no firm message about whether RPs MUST support
 XRIs or not.
   - Need to clarify how exactly XRI should be used with OpenID.
   - Similar to the whitelist question.
 - Clarify if RPs can white or blacklist what OPs they accept, and
 vice-versa.
   - Discovery of type of identifiers an RP supports.
 - Clarifying IRI
 - Updating discovery. Possibly including the new-fangled XRD  
 discovery.
 - Clarifying whether association over SSL must/can use diffie- 
 hellman.
 - Discovery of support of checkid_immediate.

 Exploratory work:
 - Signature mechanisms. Looking at additionally supporting the
 mechanisms defined in OAuth so that they can be closer together.
   - Possibly deprecating the current signature mechanism.
   - Public keys?
 - Email-shaped identifiers for OpenID
   - Could be a separate working group?

 There was consensus that email-shaped identifiers would be worked  
 on by
 a separate group and possibly rolled into 2.1 if it's done in time.

 - Smart/rich clients?
   - Could be in this WG unless it ends up being a big change in which
 case it could be its own WG.
   - There's another session about this.

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



 -- 
 Chief Architect   AIM:  gffletch
 Identity Services Work: [EMAIL PROTECTED]
 AOL LLC   Home: [EMAIL PROTECTED]
 Mobile: +1-703-462-3494
 Office: +1-703-265-2544   Blog: http:// 
 practicalid.blogspot.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: Proposal to create the TX working group

2008-11-11 Thread David Recordon
Just wanted to add that Nat is running a session on TX at IIW this  
afternoon.  We should definitly chat about the needs being expressed  
in this thread and how they might be able to be solved with OpenID.

--David

On Nov 11, 2008, at 1:13 PM, Martin Paljak wrote:

 On 09.11.2008, at 20:51, Nat Sakimura wrote:
 As to AX+SAML (or for that matter XAdES) is concerned, that is a  
 valid approach, but if I were to use SAML, I would use

 Just to clarify a technical detail: The XAdES example regarding  
 Estonia you mentioned earlier does not include transporting XAdES  
 payloads over OpenID AX (which seems to be the purpose of the  
 discussed workgroup where the similarities of SAML over AX come in).  
 The special behavior and out of band assurances given by openid.ee  
 does not include anything new on the protocol level, just added  
 semantics to basic OpenID transactions. If we could use PDF  
 signatures as legally valid signatures in Estonia, it could be PDF  
 based signatures instead of XAdES, or ODF signatures, or MS .doc  
 signatures.

 FYI, openid.ee allows a RP to upload a contract (template) which  
 must be agreed with and digitally signed (legally binding signature  
 resulting in an XAdES document with the filled in contract signed by  
 the user with an ID-card and stored on the OP) before the OP starts  
 issuing positive assertions about the given user to the given RP.  
 The contract could be a document of any kind (PDF, JPG, DOC, TXT)  
 and the only thing that is transferred to the RP over AX is a  
 'secret url' from where the RP can download the signed contract  
 (XAdES container with the possibly PDF contract in it).

 The actual assurance (that the user has signed the contract the RP  
 has uploaded) comes from out of band agreements/contracts between OP  
 and RP. The AX attribute is just an extra option, if the RP wishes  
 to automatically fetch and store the signed contract somewhere.

 Basically it is an advanced and legally binding 'I agree with terms  
 and conditions' checkbox built on top of standard OpenID.
 With legally binding I mean that it is dead simple in the court:  
 Here are the terms and conditions you digitally signed and which  
 you have violated as checking checkboxes and pressing 'continue' is  
 not a legally binding action in Estonia, at least I don't know of  
 any court cases about it.

 If you need an example use case, think of signing and faxing NDA-s  
 before you can download some simple secret product documentation.


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



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


Re: Email Address to URL Transformation

2008-11-09 Thread David Recordon

Hey Arshad,
This is now something we're talking about supporting in OpenID  
Authentication 2.1 though it isn't yet clear whether it will support a  
transformation technique like EAUT or something else.


--David

On Aug 12, 2008, at 5:35 PM, Arshad Khan wrote:


Does OpenID 2.0 support ‘Email Address to URL Transformation (EAUT)?

There is some info on this page of what EAUT is:

http://blog.vidoop.com/archives/139

Has Vidoop developed this outside OpenID 2.0 framework?

Thanks.

Arshad



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


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


Proposing an OpenID Authentication 2.1 Working Group

2008-11-08 Thread David Recordon
 OpenID Authentication and OAuth Core.   
Both OpenID Authentication and OAuth Core share a similar protocol  
flow with similar HMAC style cryptographic signing.  OAuth uses a  
slightly different and newer signing mechanism. Changing this in  
OpenID Authentication would break backwards compatibility, but the WG  
should explore the difference(s) and consider adding support for  
OAuth's mechanism alongside the current mechanism for forwards  
compatability.

Anticipated Contributions:
Specification text from a variety of contributors to achieve the goals  
listed in the above scope.

Proposed List of Specifications:
OpenID Authentication 2.1. Completion expected within the next six  
months.

Anticipated audience or users of the work:
Implementers of OpenID Providers and Relying Parties.

Language in which the WG will conduct business:
English.

Method of work:
E-mail discussions on the working group mailing list, working group  
conference calls, and possibly a face-to-face meeting at the Internet  
Identity Workshop.

Basis for determining when the work of the WG is completed:
Proposed changes will be evaluated on the basis of whether they  
increase or decrease consensus within the working group.  The work  
will be completed once it is apparent that maximal consensus on the  
draft has been achieved, consistent with the purpose and scope.

Proposers:
  - Allen Tom, [EMAIL PROTECTED], Yahoo!
  - Brad Fitzpatrick, [EMAIL PROTECTED], Google
  - Breno de Medeiros, [EMAIL PROTECTED], Google
  - Carl Howells, [EMAIL PROTECTED], JanRain
  - David Recordon, [EMAIL PROTECTED], Six Apart
  - Drummond Reed, [EMAIL PROTECTED], Parity/Cordance/OASIS
  - Gabe Wachob, [EMAIL PROTECTED]
  - Gary Krall, [EMAIL PROTECTED], VeriSign
  - John Bradley, [EMAIL PROTECTED]
  - Johnny Bufu, [EMAIL PROTECTED]
  - Joseph Smarr, [EMAIL PROTECTED], Plaxo
  - Josh Hoyt, [EMAIL PROTECTED], JanRain
  - Mart Atkins, [EMAIL PROTECTED], Six Apart
  - Max Engel, [EMAIL PROTECTED], MySpace
  - Scott Kveton, [EMAIL PROTECTED], Vidoop

Initial Editors:
  - David Recordon, [EMAIL PROTECTED], Six Apart
  - John Bradley, [EMAIL PROTECTED]






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


Re: Proposal to create the OpenID OAuth Hybrid Working Group

2008-11-08 Thread David Recordon
I see this as being really needed and quite a bunch of work has  
already gone into the doc.  I'm wondering if it would be better to  
write a Scope which describes the work and list the current draft as  
an Anticipated Contribution rather than just saw that the Scope is to  
standardize that document.


Cheers,
--David

On Nov 3, 2008, at 2:33 AM, Yariv Adan wrote:

 In accordance with the OpenID Foundation IPR policies and  
procedureshttp://openid.net/foundation/intellectual-property/   
this note proposes the formation of a new working group chartered to  
produce an OpenID specification.


As per Section 4.1 of the Policies, the specifics of the proposed  
working group are:


Background Information:
OpenID has always been focused on how to enable user-authentication  
within the browser.  Over the last year, OAuth has been developed to  
allow authorization either from within a browser, desktop software,  
or mobile devices.  Obviously there has been interest in using  
OpenID and OAuth together allowing a user to share their identity as  
well as grant a Relying Party access to an OAuth protected resource  
in a single step.  A small group of people have been working on  
developing an extension to OpenID which makes this possible in a  
collaborative fashion withinhttp://code.google.com/p/step2/.  This  
small project includes a draft spec and Open Source implementations  
which the proposers would like to finalize within the OpenID  
Foundation.



Working Group Name:
OpenID OAuth Hybrid Working Group


Purpose:
Produce a standard OpenID extension to the OpenID Authentication  
protocol that provides a mechanism to embed an OAuth approval  
request into an OpenID authentication request to permit combined  
user approval. The extension addresses the use case where the OpenID  
Provider and OAuth Service Provider are the same service. To provide  
good user experience, it is important to present a combined  
authentication and authorization screen for the two protocols.



Scope:
Standardize the draft Hybrid Protocol (http://step2.googlecode.com/svn/spec/openid_oauth_extension/drafts/0/openid_oauth_extension.html 
) as an official OpenID Extension describing how to combine an  
OpenID authentication request with the approval of an OAuth request  
token.



Anticipated Contributions:
Draft specification referenced above and various text contributions  
as more developers implement it.



Proposed List of Specifications:
OpenID OAuth Extension 1.0. Spec completion by Q4 2008.


Anticipated audience or users of the work:
 - OpenID Providers and Relying Parties
 - OAuth Consumers and Service Providers
 - Implementers of OpenID Providers and Relying Parties


Language in which the WG will conduct business:
English.


Method of work:
E-mail discussions on the working group mailing list and working  
group conference calls.



Basis for determining when the work of the WG is completed:
The work will be completed once it is apparent that maximal  
consensus on the protocol proposal has been achieved within the  
working group, consistent with the purpose and scope.



Proposers:
 - Ben Laurie, [EMAIL PROTECTED], Google
 - Breno de Medeiros, [EMAIL PROTECTED], Google
 - David Recordon, [EMAIL PROTECTED], Six Apart
 - Dirk Balfanz, [EMAIL PROTECTED], Google
 - Joseph Smarr, [EMAIL PROTECTED], Plaxo
 - Yariv Adan, [EMAIL PROTECTED], Google
 - Allen Tom, [EMAIL PROTECTED] , Yahoo
 - Josh Hoyt, [EMAIL PROTECTED] , JanRain


Initial Editors:
 - Dirk Balfanz, [EMAIL PROTECTED], Google
 - Breno de Medeiros, [EMAIL PROTECTED], Google

--
Yariv Adan | Product Manager
Google Switzerland GmbH | Identifikationsnummer: CH-020.4.028.116-1
This e-mail is confidential. If you are not the right addressee  
please do not forward it, please inform the sender, and please erase  
this e-mail including any attachments. Thanks.


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


Re: Proposal to create the TX working group

2008-11-08 Thread David Recordon
After reading the extension a few times, I'm getting caught up in  
4.1.6 (http://svn.sourceforge.jp/cgi-bin/viewcvs.cgi/*checkout*/spec/openid-trust-exchange-1_0.html?root=openidtx#anchor7 
) which references amounts being paid, currency, contracts, terms of  
the contract, etc.  Overall, I'm pretty confused about what this  
extension does (it seems to do a lot of different things) which is  
making it hard for me to determine a better name.  I also still feel  
that the reuse of AX (for it's extensibility) combined with the  
ability to exchange signed SAML tokens is a more future proof method  
and something that will be easier to be widely adopted as OpenID  
continues to evolve.


--David

On Nov 8, 2008, at 11:14 PM, Drummond Reed wrote:


+1. “OpenID Trust Extension” seems like a good fit.

=Drummond

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On  
Behalf Of Nat Sakimura

Sent: Saturday, November 08, 2008 12:22 PM
To: [EMAIL PROTECTED]
Cc: specs@openid.net
Subject: Re: Proposal to create the TX working group

Maybe just OpenID Trust Extension just like WS-Trust?

=nat
On Sun, Nov 9, 2008 at 5:06 AM, Nat Sakimura [EMAIL PROTECTED]  
wrote:

Hi David,

I do not have any particular attachment to trust exchange. So, I  
am ok in changing it but it would be nice if I can preserve TX  
acronym though. Do you have any specific suggestions?


=nat

On Sun, Nov 9, 2008 at 3:50 AM, David Recordon  
[EMAIL PROTECTED] wrote:

Hi Nat,
Thanks.  I still would really like to see the name changed for when  
we think about the World-wide market.  Do others disagree?  OpenID  
Trust Exchange just feels like it doesn't actually describe what the  
spec does nor how you can actually exchange trust.


--David

On Nov 1, 2008, at 2:19 AM, Nat Sakimura wrote:


Hi David,

Thanks for your comments. My reply inline below:

2008/11/1 David Recordon [EMAIL PROTECTED]
Hey Nat,
Do you see this as being built atop Attribute Exchange for transport  
or as something new that TX defines?  I know Sxip had done work with  
AX to enable passing signed and encrypted attributes using SAML  
assertions.


I have thought of using AX as transport once, then gave up on it  
when I was thinking of a mobile use case where the amount of payload  
that could be carried with was very limited (URL length in GET is  
limited to one of 128bytes, 256bytes or 512bytes depending on the  
handset). So, the current draft looks a lot like AX with bunch of  
hard coded attribute types in a way.


As far as carrying SAML token etc. in AX are concerned, similar  
thing has also been done by one of the proposer, Robert Ott of  
Clavid. Martin Paljak of Estonia (openid.ee) has been using XAdES  
with AX.
These approach are valid. However, I thought the approach partly  
defeats the purpose of OpenID.

If we were using SAML, then we could have used it through out.
I wanted to make it easier for the developers by sticking to the tag- 
value approach.
This made us define some of the attribute types defined in SAML and  
XAdES to be defined as tag-value tag.




Is Trust Exchange really the best name?  Seems like trust is  
quite a broad concept so something more specific might be better.


Right. Naming was a bit problematic. I started using Trust because  
the messaging model is not dis-similar to WS-Trust. Now, the trust  
defined in WS-Trust in our context is essentially Contract. So I  
thought of changing it to CX or something, but then, at least in  
Japan, quite a few key people were already exposed to TX by now  
and thus I kept the name TX.




--David

On Oct 31, 2008, at 4:21 AM, Nat Sakimura wrote:


Dear Specification Council members:

In accordance with the OpenID Foundation IPR policies and  
procedures this note proposes the formation of a new working group  
chartered to produce an OpenID specification.  As per Section 4.1  
of the Policies, the specifics of the proposed working group are:



Trust Exchange (TX) Extension WG Charter

In accordance with the OpenID Foundation IPR policies and  
procedures this note proposes the formation of a new working group  
chartered to produce an OpenID specification.  As per Section 4.1  
of the Policies, the specifics of the proposed working group are:



Proposal:

(a)  Charter.

 (i)  WG name:  Trust Exchange Extension (TX)

 (ii)  Purpose:  The purpose of this WG is to produce a standard  
OpenID extension to the OpenID Authentication protocol that  
enablesarbitrary parties to create and exchange a mutually- 
digitally-signed legally binding contract. This protocol  
extension aims to be both broadband and mobile friendly by defining  
appropriate bindings for each use case.


Although this specification defines one default protocol for  
transfering data based on the contract, the data transfer portion  
is intended to be pluggable so that other protocols may also be  
used for this purpose.


The extension is not intended to be a general method for defining  
attributes; the scope is limited

Fwd: [xrds-simple] Refocusing XRDS / XRDS-Simple / Discovery

2008-11-01 Thread David Recordon
This is worth reading as it outlines what Eran plans to do with the  
current XRDS and XRDS-Simple specifications.  It will have future  
implications on OpenID as the current Yadis discovery protocol  
actually violates the HTTP and web architecture (as pointed out by the  
W3C).  I'm going to be following this work and figure a future version  
of OpenID should make use of it.  That will mean that OPs will likely  
need to support the new discovery mechanism while also supporting the  
current one for a period of time as it becomes deprecated.


cc'ing Eran in case there are questions, but the discussion is  
occuring on the XRDS Simple list at http://groups.google.com/group/xrds-simple 
 for the time being.


--David

Begin forwarded message:


From: Eran Hammer-Lahav [EMAIL PROTECTED]
Date: October 27, 2008 3:06:41 PM PDT
To: [EMAIL PROTECTED] [EMAIL PROTECTED]
Subject: [xrds-simple] Refocusing XRDS / XRDS-Simple / Discovery
Reply-To: [EMAIL PROTECTED]

I have been reviewing XRDS and XRDS-Simple for the past couple of  
months, including their relationship to HTTP, web architecture, and  
most importantly, the use cases that are driving the development of  
an HTTP discovery protocol. What I am most interested in has always  
been a protocol for discovering metadata about an HTTP resource.  
This metadata is focused on two things: the resource itself, and its  
relationship to other resources.


Brand / Document Type

I would like to change focus from XRDS/XRDS-Simple to XRD. XRDS as a  
sequence of XRD elements is specific to XRI resolution where the  
sequence of XRDs adds value. The inclusion of multiple XRD elements  
does not fit within the model of a document describing a resource.  
My proposed use of URI fragment together with xml:id attributes ads  
much complexity and little value and will be dropped.


I propose to name this specification ‘XRD: Extensible Resource  
Descriptor’. There is existing value in the XRDS and XRDS-Simple  
brands, but it is extremely low outside the social-web/identity echo- 
chamber. Pushing out a somewhat new brand of XRD with a simple  
acronym (Extensible Resource Descriptor) goes a long way in  
delivering our message.


Focusing on the application/xrd+xml and XRD schema will also make  
the transition easier as there will be less overlap in headers,  
elements, and existing documents. By offering an XRD-top-level  
document, there is less chance of conflicting with existing XRI and  
OpenID documents.


This effort should be branded as XRD 1.0. XRDS is currently in  
version 2.0 (which failed an OASIS vote) and is now planned to  
become 3.0. I think that for branding purposes, starting with  
version 3.0 is counterproductive, but I do not have strong opinions  
in the version number. One idea I like is to drop the version and  
use a date instead (common for W3C standards).


Another advantage of keeping XRDS XRI-specific is that the current  
XRDS element not included in the new XRD schema will be able to get  
assigned to the XRDS namespace which will prevent the need to define  
a third namespace just for XRI-specific elements (on top of the XRDS  
and XRD namespaces).


Venue / Namespace

XRD is a product of the OASIS XRI TC and if for no other reason than  
to give proper attribution, should stay anchored there. I intend to  
draft and publish the XRD specification as a product of the XRI TC  
and will be joining OASIS in the next few days. As an OASIS  
standard, the XRD schema should have an OASIS http namespace (http://docs.oasis-open.org/ns/xri/xrd/1.0 
 or http://docs.oasis-open.org/ns/xri/xrd/2008/11).


However, much of the relevant community to a generic HTTP discovery  
mechanism and resource metadata resides in the IETF where HTTP is  
defined and evolved. I would like to find a way to publish OASIS  
drafts simultaneously as IETF I-Ds for informational purposes only.  
At the end, I would like to see the OASIS standard assigned an IETF  
RFC number. Again, this is not a proposal for standardization at the  
IETF, just using the RFC as a publication channel. This proposal  
needs much discussion by the XRI TC and would ultimately be their  
decision.


Discovery Workflow

The entire discovery workflow defined by Yadis will be replaced in  
XRD. Support for the ‘Accept’ HTTP header will be removed as it  
violates HTTP and web architecture. The direct-access use case (of  
accessing the metadata document without interacting with the  
resource itself) will be supported using the new /site-meta proposal  
[1] with a dynamic map to transform the resource URI to the metadata  
URI. The resource metadata map functionality will be added to the  
next draft of the /site-meta proposal or published as a separate  
proposal.


The plan is to add support for mapping between a resource’s URI to  
the URI of its metadata document by using a URI template. Currently,  
the draft only covers links to site-wide metadata. However, there  
are use cases in which 

Re: Proposal to create the TX working group

2008-10-31 Thread David Recordon

Hey Nat,
Do you see this as being built atop Attribute Exchange for transport  
or as something new that TX defines?  I know Sxip had done work with  
AX to enable passing signed and encrypted attributes using SAML  
assertions.


Is Trust Exchange really the best name?  Seems like trust is quite  
a broad concept so something more specific might be better.


--David

On Oct 31, 2008, at 4:21 AM, Nat Sakimura wrote:


Dear Specification Council members:

In accordance with the OpenID Foundation IPR policies and procedures  
this note proposes the formation of a new working group chartered to  
produce an OpenID specification.  As per Section 4.1 of the  
Policies, the specifics of the proposed working group are:


Trust Exchange (TX) Extension WG Charter

In accordance with the OpenID Foundation IPR policies and procedures  
this note proposes the formation of a new working group chartered to  
produce an OpenID specification.  As per Section 4.1 of the  
Policies, the specifics of the proposed working group are:



Proposal:

(a)  Charter.

 (i)  WG name:  Trust Exchange Extension (TX)

 (ii)  Purpose:  The purpose of this WG is to produce a standard  
OpenID extension to the OpenID Authentication protocol that enables  
arbitrary parties to create and exchange a mutually-digitally-signed  
legally binding contract. This protocol extension aims to be both  
broadband and mobile friendly by defining appropriate bindings for  
each use case.


Although this specification defines one default protocol for  
transfering data based on the contract, the data transfer portion is  
intended to be pluggable so that other protocols may also be used  
for this purpose.


The extension is not intended to be a general method for defining  
attributes; the scope is limited to a specific set of attributes  
necessary for contract semantics. The extension will also define a  
contract signature based on public key cryptography. When used with  
a digital certificate signed by a third party, the contract and  
signature can be used as an assertion of conformance to an  
applicable assurance program.


 (iii)  Scope:

Scope of the work

   Development of the specification including:
An extensible tag-value contract format
Public Key Cryptography based digital signature method applied to  
the above contract format

Query/response communication protocols for establishing the contract
Default data transfer protocol based on the contract
Conformance requirements for other data transfer protocol bindings
Security, threats and Risk analysis
Perform Security Risk analysis and profiles for best practice
 Out of scope

Term negotiation: Actual negotiation of the terms of a contract  
should be dealt with out-of-band or by other specifications.
General purpose data type identifiers: this should be determined on  
a per-community bases using other specifications such as OpenID  
Attribute Exchange.

Assurance programs or other identity governance frameworks.
It is the intent that this specification be usable by any trust  
community, whether it uses conventional PKI hierarchies, peer-to- 
peer trust mechanisms, reputation systems, or other forms of trust  
assurance. The specification of any particular trust root, trust  
hierarchy, or trust policy is explicitly out of scope.


 (iv)  Proposed List of Specifications:  TX 1.0, spec completion  
expected in January 2009.


 (v)  Anticipated audience or users of the work:  Implementers of  
OpenID Providers and Relying Parties, especially those who require  
security and accountability features to exchange sensitive customer  
information (e.g. personally identifiable information and credit  
card numbers) responsibly among trusted parties.


 (vi)  Language in which the WG will conduct business:  English.

 (vii)  Method of work:  E-mail discussions on the working group  
mailing list, working group conference calls, and possibly face-to- 
face meetings at conferences.


 (viii)  Basis for determining when the work of the WG is  
completed:  Draft 1 will be evaluated on the basis of whether they  
increase or decrease consensus within the working group.  The work  
will be completed once it is apparent that maximal consensus on the  
draft has been achieved, consistent with the purpose and scope.


(b)  Background Information.

 (i)  Related work being done by other WGs or organizations:

LIberty Alliance Identity Governance Framework (IGF) 1.0 Draft
XML Advanced Electronic Signatures (XAdES)

 (ii)  Proposers:

   Drummond Reed, [EMAIL PROTECTED], Cordance/Parity/OASIS  
(U.S.A)

   Henrik Biering, [EMAIL PROTECTED], Netamia (Denmark)
   Hideki Nara, [EMAIL PROTECTED], Tact Communications (Japan)
   John Bradeley, [EMAIL PROTECTED], OASIS IDTrust Member Section  
(Canada)

   Mike Graves, [EMAIL PROTECTED], JanRain, Inc. (U.S.A.)
   Nat Sakimura, [EMAIL PROTECTED], Nomura Research Institute,  
Ltd.(Japan)

   Robert Ott, [EMAIL PROTECTED], Clavid (Switzerland)
   Tatsuki Sakushima, 

XRDS-Simple 1.0 Draft 1 Released

2008-03-29 Thread David Recordon
If you haven't taken a look about XRDS-Simple -- and care about Yadis  
or XRDS Based Discovery -- then you should!


The blow by blow history is:
1) Brad Fitzpatrick, Johannes Ernst, and I were looking at merging  
OpenID and LID in 2005 and needed a discovery protocol.  Made a text  
based one but knew XML would be useful.
2) At the first IIW in Oct. 2005 we learned about XRDS and thought it  
would be useful.
3) A group of 20ish people created Yadis 1.0 in Jan. 2006 which  
extracted XRDS from XRI Resolution and described how to discover an  
XRDS document via HTTP.

4) Yadis 1.0 was published and it started to be used with OpenID 1.1.
5) The OASIS XRI TC incorporated the HTTP based discovery of a XRDS  
document as Chapter 6 of the XRI Resolution spec.

6) OpenID 2.0 has XRDS Based Discovery, referencing Chapter 6.
7) The OAuth (http://oauth.net) community needs a discovery protocol  
and looks at using Yadis.
8) Eran Hammer-Lahav realizes that Yadis isn't a fully separate  
compliant profile of XRDS from XRI Resolution.

9) Eran works with the XRI TC and others to develop XRDS Simple.
10) Today.

Using XRDS Simple shouldn't actually change discovery in OpenID,  
rather give us a shorter specification to reference when dealing with  
URL identifiers and a clear subset of what needs to be supported by  
XRDS Simple (Yadis) parsing libraries.


More on the why in Eran's blog at http://www.hueniverse.com/hueniverse/2008/03/putting-xrds-si.html 
.


--David

Begin forwarded message:


From: Eran Hammer-Lahav [EMAIL PROTECTED]
Date: March 26, 2008 6:21:48 PM PDT
To: [EMAIL PROTECTED] [EMAIL PROTECTED]
Subject: [OpenID] XRDS-Simple 1.0 Draft 1 Released

http://xrds-simple.net/core/1.0

I’m happy to announce that XRDS-Simple 1.0 Draft 1 was released  
today. What started as an appendix to OAuth Discovery, quickly found  
life of its own in the form of a generic and simple-to-implement  
discovery protocol for web services. The specification is more about  
an editorial review of existing standards than an invention of  
something new, but written to remove the need to study other  
specifications.


From the XRDS-Simple specification:
---
XRDS-Simple provides a format and workflow for the discovery of  
resources metadata, and other linked resources. As web services  
continue to grow, applications utilize a wider range of web services  
and resources across multiple providers. XRDS-Simple allows  
providers to document their resources in a machine-readable way,  
which can be automatically discovered by consumer applications.


The XRDS-Simple specification builds on top of existing practices  
first introduced by the XRI community and later adopted and further  
developed by Yadis, a discovery protocol widely used by the OpenID  
community. XRDS-Simple goal is to provide an easy to implement  
solution that is focused on solving the most common discovery use  
cases.


The goal of XRDS-Simple is to provide a lightweight version of XRDS  
that simplifies the implementation of parsers while maintaining full  
compatibility with XRDS and any XRDS-compliant parsers and  
resolvers. It also serves as an introduction to XRDS, giving  
implementers an upgrade path to other XRDS features when appropriate.


By defining XRDS-Simple, implementers can both declare the scope of  
their application and capabilities, as well as perform tests to  
assert that their application is capable of processing input  
documents exactly as they were intended. This is of particular  
importance when processing documents with security or identity  
information, where misinterpretation of the document can lead to a  
breach of security.

---

XRDS-Simple is being developed with the full support and  
participation of the XRI TC, and members of the OpenID, OAuth, and  
DiSo communities. The specification is available at http://xrds-simple.net/core/1.0 
 and its discussion maintained at the XRDS-Simple Google Group (http://groups.google.com/group/xrds-simple 
).


Feedback is greatly needed and appreciated.


EHL
http://www.hueniverse.com/hueniverse/2008/03/announcing-xrds.html

___
general mailing list
[EMAIL PROTECTED]
http://openid.net/mailman/listinfo/general


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


Fwd: [OpenID] The 3xx Redirect Debate

2008-03-29 Thread David Recordon
Wanted to make sure everyone saw this, though please reply to it on  
the General list since the majority of the discussion ended up  
happening over there.

--David

Begin forwarded message:

 From: David Recordon [EMAIL PROTECTED]
 Date: March 29, 2008 1:19:39 AM PDT
 To: OpenID List [EMAIL PROTECTED]
 Subject: [OpenID] The 3xx Redirect Debate
 Reply-To: [EMAIL PROTECTED]

 Wow!  Just got done reading the threads both on this list and the
 specs list.  Certainly a lot of passion in the discussion and good
 points being made all the way around.  It was a little disheartening
 to see how brusk it got at times (arguing about what mailing list to
 use wasn't really moving the discussion forward).  I'm sending this  
 to [EMAIL PROTECTED]
  (and will forward a copy to specs@openid.net) since the majority of
 the discussion took place on general, even though it was probably
 better suited for specs.  That said, let me see if I can help provide
 a few clarifying thoughts.

 Completely ignoring technology for a moment, Noah's use case of being
 able to enter his domain and have it be displayed / treated as his
 OpenID at a Relying Party while having a browser redirect to /about/
 for normal people seems quite reasonable.  I have a gut feeling that
 this is a relatively rare practice (guessing most people don't think
 about doing it), but from a user experience perspective I like it.

 From a technology perspective, as the discussion very clearly showed,
 making this work with some form of predictable backwards compatibility
 isn't easy.  With that in mind, the number of OpenIDs that currently
 issue a 303 redirect is probably fairly small since I would imagine
 that the majority of people don't understand the difference between
 301, 302, and 303.  I know it took me re-reading RFC 2616 and
 Wikipedia a few times.

 From a historical perspective the original OpenID 1.1 specification
 said:
 Note that the user can leave off http://; and the trailing /.  A
 consumer must canonicalize the URL, following redirects
 and noting the final URL.  The final, canonicalized URL is the
 user's identity URL.

 It, and now the 2.0 spec as well, do not differentiated between the
 type of HTTP redirect that is occurring.  Rather, an OpenID RP
 following the OpenID specification would follow any type of
 redirect(s) (making its own choice of how many is too many as RFC 2616
 infers) and then if successful treat the resulting URL as the user's
 OpenID claimed identifier.  It would then perform discovery on that
 resulting URL, looking for a provider or delegation information.
 While certainly not to the HTTP spec, I believe the original intent
 was to conflate the various types of redirects into a single meaning
 for OpenID.  Is that right, maybe not, but it does make the simple
 cases simpler.

 The largest problem I see is that in the wild there is a lack of
 consistent understanding and behavior around 3xx response codes.  A
 302 is often used when a 301 should be, a 302 is treated as a 303, and
 I doubt the difference between a 302 and a 307 is widely understood.
 301, 302, and 307 are clearly pretty similar and I do agree that a 303
 is designed to be treated a bit differently; See Other versus
 talking about something being found, moved, or redirected.  I could
 see the case being made that an OpenID RP should treat a 301, 302, or
 307 as a 301 (current behavior of use the final URL after all
 redirects) and then a 303 treated as a different form of OpenID
 delegation.  (Since delegation is basically saying I'm URL A, but I
 can prove I also own URL B which I delegate to which is similar to
 Noah's use case of I'm URL A, but people should see me at URL B, and
 URL B delegates to my provider.)  This would add future support for
 Noah's use case while probably breaking a small number of OpenIDs.

 I don't have a clear answer, but I do agree that a future revision of
 OpenID Authentication should spell out clearly what to do with these
 various 3xx codes.  I think the first step there is some real research
 into the actual use of 303 on the web as it might relate to OpenID.

 Noah, thanks for bringing this up!

 --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] Problems with OpenID and TAG httpRange-14

2008-03-10 Thread David Recordon
I don't see why changes would really need to wait, if there is an  
interested group of people then lets spin up a mailing list and get  
participants to agree to the IP policy.

The entire goal of having working groups and seperate mailing lists  
is to help ensure that future OpenID specs are not encumbered with  
intellectual property issues.  The easiest, and most common, way to do  
this is creating seperate technical working mailing lists based around  
related topics or a specification.  This allows people to choose where  
they wish to participate since the requirement of posting to one of  
these lists is agreeing that your contributions are being made under  
the OpenID IPR Policy.

This list (specs@openid.net) is a great place to identity issues that  
need addressing and figuring out who wants to work on solving them.   
Once that happens, I have no problem helping to make it legit so  
that the resulting spec is good from an IP perspective.

--David

On Mar 10, 2008, at 12:46 PM, Drummond Reed wrote:

 -Original Message-
 From: Noah Slater [mailto:[EMAIL PROTECTED]
 Sent: Monday, March 10, 2008 1:43 AM
 To: Drummond Reed
 Cc: specs@openid.net
 Subject: Re: [OpenID] Problems with OpenID and TAG httpRange-14

 Noah, you are in the right place (and the General list is the wrong
 place, which is why I have removed that cc).

 Okay, thank you.

 Once those groups start, they will each have dedicated mailing  
 lists. In
 the meantime, this is the list for discussing any spec issues. So  
 far
 one OpenID Authentication 2.0 editor, Johnny Bufu, has commented on
 the thread you started.

 Im a little confused about what this means. Does this mean that  
 this issue
 will not get properly looked at until such time as the new WGs have  
 been
 set up?

 It doesn't mean it won't get looked at or discussed here. However  
 any
 formal changes to the specifications must wait until these WGs are  
 started.

 Is there anywhere further to go from here?

 No, this is the right place, and until the WGs are started, any  
 discussion
 should take place on this list.

 I'll bring it up at the next OpenID Foundation board meeting (this  
 Thursday)
 so board members are aware of this issue.

 =Drummond

 ___
 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: handling of url redirection

2008-02-23 Thread David Recordon
Hi Marv,
This has never been specified as a relying party could choose to  
follow as many redirects as it wishes.  Maybe there should be a hard  
line drawn though from an interoperability side?

--David

On Feb 17, 2008, at 3:06 PM, SignpostMarv Martin wrote:

 Was talking with keturn in #openid , and it seems that the spec
 currently doesn't indicate how 30x redirects should be handled.

 More specifically, how deep an OpenID-enabled application should  
 follow
 redirects before giving up.


 ~ Marv
 ___
 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 3.0

2008-02-08 Thread David Recordon
+1.  Let's get 2.0 deployed and figure out what it might be lacking  
before just starting on 3.0.

On Feb 3, 2008, at 11:05 PM, Johannes Ernst wrote:

 Amen. Let's build (optional) extensions, and only if that absolutely
 does not work for an essential feature, meekly suggest that the
 smallest possible set of changes be made to an existing spec.

 Note that any term such as OpenID 3.0 is mostly a marketing /
 branding term, just like OpenID 2.0. What it really means is what
 underlying specs are being packaged into a larger term.

 On Feb 2, 2008, at 2:36, Martin Atkins wrote:


 I apologise that this message doesn't directly address any of the
 points
 you've made, but others have been doing that.

 I just want to make a general point:
 In my opinion, we should resist the urge to start specing OpenID  
 3.0
 (aka OpenID vNext) and try to do everything else that needs to be  
 done
 with extensions now. OpenID 2.0 has laid the framework for
 decentralized
 extensibility, so it should now be much easier to work within that
 framework.

 If it turns out that some particular feature absolutely can't be done
 without making a new Authentication spec release then so be it, but
 ideally I think we want 2.0 to be stable for many years to come to
 avoid
 repeating all of the current pain of incompatible versions and the
 poor
 user experience that creates.


 McGovern, James F (HTSC, IT) wrote:
 Figured I would ask if anyone is interested in brainstorming the  
 next
 version of OpenID and how it can be used in Enterprise B2B settings
 and
 not solely focusing on consumerish interactions. Some things that I
 would like to see in the next version are:

 1. A discussion on how AuthZ can converge with OpenID
 2. Modeling of relationships
 3. Not allowing an OpenID to be a vector for SQL Injection and
 putting
 something around what it should look like
 4. A way to indicate to the relying party what level of
 authentication
 has occurred such as did the OP check a password, how did it
 validate a
 user. Without this, there is no way that a trust model could be
 established in a credible way.

 5. A way for OpenID relying parties to filter out Ops. In a business
 scenario, if I run the Sun employee store, I may only want the Sun
 OP to
 talk with me.

 ___
 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: OAuth + OpenID

2008-01-12 Thread David Recordon
Great, thanks!  We're talking about these drawing at OpenIDDevCamp  
right now.

Thanks,
--David

On Dec 11, 2007, at 7:33 PM, NISHITANI Masaki wrote:


 I enumerated all possible cases to use OAuth and OpenID
 together to organize my thought a bit more.

 And correct the charts for one misunderstanding.
 In cahrt 3, there should be another user-interaction phase
 for SP, which behaves as a relying party in OpenID context,
 to obtain user identifier.

 I will be grad with any comment to this.

 Possible cases to use OAuth and OpenID together.
 

 1. Consumer, SP and OP all differ (4-entity case)

  1.1 Both of Consumer and SP does not use OpenID at all.
- This is just a simple OAuth usecase (chart 1).

  1.2 Consumer requires OpenID authentication, SP does not.
- Same as simple OAuth except place OpenID transactions
  before initiating OAuth (above all chart 1 sequence).

  1.3 SP requires OpenID authentication, Consumer does not.
- Chart 3.

  1.4 Both requires OpenID authentication.
- Almost same as chart 3. Just place another OpenID
  sequences above all of lines.

 2. Consumer and SP are same.

  Does not need to use OAuth.

 3. SP and OP are same.

  3.1 Consumer does not use OpenID.
- Simple OAuth.

  3.2 Consumer does use OpenID.
- Sequences are just same in chart 3, or possibly
  optimize like chart 4.

 4. Consumer and OP are same.

  4.1 SP does not use OpenID
- Sinple OAuth.

  4.2 SP uses OpenID
- This is a bit strange case. It is possible to use
  OpenID authentication for SP, but it is meaningless.
  OAuth aims to data exchange without desclosing user
  credentials and in this case, consumer already knows
  user credential because it is a OpenID provider
  itself.

 5. All same.
  Surprisingly, does not need OpenID nor OAuth.
  Let me call this ``plain old web service'' ;-P


 Hi all.

 According to the theme, OAuth and OpenID, talked in the IIW
 2007b, I have made up a brief diagrams for a sort of
 self-brainstorming.

 It is a shame for me not have been able to join in that
 session in IIW, though regarding the wiki page placed at
 http://iiw.idcommons.net/index.php/OAuth_and_OpenID ,
 it went over mainly about a case of SP (it's an OAuth term)
 and OP (OpenID term) are same one.

 Now the diagrams consists of -

 Page 1; Ordinary OAuth sequence chart.
 Page 2; Same for OpenID.
 Page 3; Using OAuth and OpenID together,
  Consumer does not need authorization but access to
  user's data stored in SP, and SP uses OpenID for its
  authorization method.
 Page 4; Superimposing OAuth and OpenID,
  SP and OP are same one and consumer requires user's
  data stored in OP/SP and uses OpenID as well.

 This is a starting point for me and now I am looking for any
 other use case and trying to make myself clear.

 Probably there is some chances to make the protocols
 simpler. One case is to skip association phase using the
 Consumer secret or RSA key of the consumer to verify
 consumer/RP.

 I will be grad if I have comments.


 

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

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


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


Finalizing OpenID Authentication 2.0 and OpenID Attribute Exchange

2007-12-01 Thread David Recordon
Hey all,

While its certainly been a long process in the making, it seems that
we're now in a position to declare OpenID Authentication 2.0 and OpenID
Attribute Exchange as final specifications. Both have evolved through
extensive community participation and feedback and each are stable as
Implementor Drafts for a number of months now. Both specifications are
already shipping in some libraries and products including Google's
Blogger (via Sxip's library) and Drupal who did their own implementation
of the specification and multiple OpenID Providers with support for both
of these specifications as well. Additionally the following libraries
exist which implement OpenID Authentication 1.1 and 2.0, OpenID Attribute
Exchange, and OpenID Simple Registration 1.0:

 - http://code.sxip.com/openid4java/ - Java OpenID library from Sxip
 - http://code.google.com/p/joid/ - Java OpenID library from Verisign
 - 
http://framework.zend.com/fisheye/browse/Zend_Framework/trunk/library/Zend/OpenId
 - http://OpenIDEnabled.com/ - PHP, Python, and Ruby libraries

As part of the IPR work over the past few months we've begun collecting
non-assertion agreements from contributors to both of these
specifications. These agreements are a way for contributors (and others)
to these specifications to formally declare that they will not assert
any patent rights against OpenID implementations. The majority of them
are in and the goal is to have any remaining in by the Internet Identity
Workshop this coming Monday through Wednesday. When this happens we'll
be creating a page on OpenID.net so that everyone can find the various
agreements as well as copies of them that have been signed.

As soon as all of the non-assertion agreements are in, I very strongly
+1 making these two specifications final to be announced at IIW this
coming week.

Cool? Cool!

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


Re: [security] Phishing-Resistant Authentication definition

2007-11-20 Thread David Recordon

Do you have proposed wording for this?

It might also make sense to rename this policy to something like No  
Shared Secret and then also draft a second policy which allows shared  
secrets which are more resistant to phishing than passwords.  In the  
end, not calling anything phishing resistant may be beneficial to  
resolving everyone's concerns.


Thanks,
--David

On Nov 20, 2007, at 1:32 PM, Dick Hardt wrote:

Recently this definition of Phishing-Resistant Authentication was  
proposed:




· Phishing-Resistant Authentication
An authentication mechanism where the End User does not provide  
shared secrets to a party potentially under the control of the  
Relying Party that could enable that party to then authenticate  
elsewhere as if it were the End User. (Note that the potentially  
malicious Relying Party controls where the User-Agent is  
redirected to and thus may not send it to the End User's actual  
OpenID Provider).


Given the rise of nasty MITM malware, I hope that we all agree that  
PAPE is not intended to protect the user from malware on their own  
machine, but to protect the user from malicious websites. If so,  
would it make sense to enhance the definition to reflect this?


-- Dick
___
security mailing list
[EMAIL PROTECTED]
http://openid.net/mailman/listinfo/security


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


Fwd: OSIS PAPE call results

2007-11-05 Thread David Recordon

Hey all,
It turned out that from the OSIS interoperability event in Barcelona a  
call was scheduled to discuss PAPE issues from the interop.  I heard  
about the call a few minutes before, but Mike, Johnny, and I had a  
really productive call.  If no one disagrees, we should get these  
edits into the spec and release draft 3.


Thanks,
--David

Begin forwarded message:


From: Mike Jones [EMAIL PROTECTED]
Date: November 1, 2007 10:04:02 PM GMT+01:00
To: [EMAIL PROTECTED] [EMAIL PROTECTED], Johnny Bufu [EMAIL PROTECTED] 
, [EMAIL PROTECTED] [EMAIL PROTECTED]

Subject: OSIS PAPE call results

Today we held the call discussing OSIS feedback on the PAPE spec.   
Topics covered and recommendations made on the call were:


- Authorization decisions should be made solely by the relying  
party.  The identity provider should accurately report the status of  
all policies requested by the relying party that the authentication  
complies with and may also choose to report the status of any  
policies that apply that were not explicitly requested.  The  
policies are not mutually exclusive and no relationship between the  
different policies should be implied.  A clarification to this  
effect should be added to the draft.


- There was a request for a definition of Active Authentication as  
used in the auth_time element description.  Intuitively, this  
involves at least having the user being at the machine as a  
participant in the authentication interaction in some manner.  We  
agreed that we should look for an existing definition of active  
authentication that appears to apply.


- The table in Appendix A.1.1 of http://openid.net/specs/openid-provider-authentication-policy-extension-1_0-02.html 
 needs to be updated to be consistent with the definition in Section  
4.  Specifically:
PIN and soft OTP token should not be marked as phishing- 
resistant.
PIN and hard OTP token should not be marked as phishing- 
resistant.
Information Cards should be added and listed as phishing- 
resistant.
Active password managers that only release the password  
to the correct site should be listed as phishing-resistant.


- If relying parties and OPs want to communicate actual  
authentication methods used, that should happen via a different spec  
than PAPE.  Then the market can decide whether to use PAPE, this  
spec, both, or neither.  (However some in the group have both  
privacy concerns about this and concerns about enabling attackers by  
giving them additional information to use in their attacks.)


Finally, while we failed to discuss this on the call, I also believe  
that:
PIN and digital certificate via HTTPS is phishable if  
the same certificate value is released to every site.
PIN and digital certificate via HTTPS is not phishable  
if a different certificate value is released to every site.
and that the table should be updated accordingly in this case as  
well.  Someone who's an expert in this method should pipe in and  
provide guidance.


Thanks all!
-- Mike



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


Re: SREG namespace URI rollback

2007-11-01 Thread David Recordon
Sorry it took me a few days, but seems alright to me.  I think a  
larger question would be if there should be any material differences  
with SREG 1.1 such as adding a few additional common fields.

-David

On Oct 26, 2007, at 4:51 PM, Johnny Bufu wrote:

 David, Josh,

 Reviving an old thread here...

 On 2-Apr-07, at 5:06 PM, Johnny Bufu wrote:

 After a chat with Josh, we settled our dispute by agreeing on the
 following:

 On 2-Apr-07, at 2:44 PM, Josh Hoyt wrote:
 I think it would be reasonable to always use sreg, if for no other
 reason than for clarity, but re-using the Type URI as the namespace
 alias instead of creating a new one does not imply that the alias  
 must
 be sreg when using OpenID 2.

 What if I put my proposal this way:

 If Simple Registration is used with OpenID 1, the arguments MUST be
 prefixed with openid.sreg. If Simple Registration is used with
 OpenID 2, the arguments MUST be in the namespace
 http://openid.net/sreg/1.0;

 The first bit allows a implementation of SREG1.1/OpenID2 to be
 seamlessly used in compatibility mode with OpenID1 messages, which
 (together with the last two items in the proposal) would eliminate
 the conflicts I was pointing out.

 Can the latest draft of SREG1.1 please be updated as per above?

 This is causing two issues at this time:

 - OpenID4Java libraries (and Sxip deployments) were implemented as  
 per above (and the according design), assuming the update to the  
 spec would be done in the near future;
 JanRain libraries however still use the published http://openid.net/sreg/1.1 
  URI for SREG1.1. This leads to interop issues between the two.

 - In the recently publish OP comparison chart, Sxipper appears as  
 not supporting SREG1.1 (and for good reason from the point of view  
 of Will's scripts and published specs).


 Thanks,
 Johnny




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


Re: Some PAPE Wording Clarifications

2007-10-23 Thread David Recordon
I see both sides of this.  At the end of the day the RP is ultimately  
making the decision as to if the user can proceed or not.  Just as in  
SREG if the RP says email is required and the user/OP choose not to  
provide it, the RP still has to decide what to do.

I do agree that it is easier on a RP to not have to understand any  
relationships between policies.  In this case of the three defined  
policies I see that as less important, but the argument that it  
becomes increasingly likely that the RP may not understand a given  
policy created by an OP is quite legit.  Also as you argue, the OP  
knows what actually happened so can best place that within the policies.

I'm alright changing the recommendation to the OP at least including  
the specific policies requested by the RP and shifting some of that  
burden back to the OP.  That also is in line with general OpenID  
philosophy of making the OP do the heavy lifting.

Barry, I was talking to you about this yesterday, you alright with  
this as well?

In any-case, lets get Draft 2 out in the next 2-3 hours.

Thanks,
--David

On Oct 23, 2007, at 10:05 AM, Johnny Bufu wrote:


 +   [...] For example it is recommended that if the OP
 +specified the Multi-Factor Physical Authentication policy  
 and the RP
 +requested the Multi-Factor Authentication policy, that the  
 RP's
 +requirements were met.

 This puts undue requirements on the RP implementations. As a design  
 principle, I believe the goals were to make required effort and  
 adoption and as easy as possible for RPs, and have more happening  
 on the OP where possible. I would at least complement, if not  
 replace, this patch with:

 For example, if the RP requested Multi-Factor and the OP supports  
 Multi-Factor Physical, it is recommended that the OP includes both  
 policies in the response.

 As I argued on the osis list, the OP is in the best position to  
 make judgments about the qualities of its authentication  
 mechanisms, and it should respond to the point to the RP's  
 requests. What if the RP knows what Multi-Factor means, but has no  
 idea (and no interest) in Multi-Factor-Physical?


 Johnny



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


Re: Some PAPE Wording Clarifications

2007-10-23 Thread David Recordon
Cool, committed.
http://svn.openid.net/diff.php?repname=specificationspath=% 
2Fprovider_authentication_policy_extension%2F1.0%2Ftrunk%2Fopenid- 
provider-authentication-policy-extension-1_0.xmlrev=378sc=1

We ready to publish Draft 2?

--David

On Oct 23, 2007, at 2:46 PM, Barry Ferg wrote:

 Yes, there are arguments to be made for both sides here.  I have to
 agree with Johnny and David's point on this; lets give the RP what it
 can be reasonably expected to understand.

 On 10/23/07, David Recordon [EMAIL PROTECTED] wrote:
 I see both sides of this.  At the end of the day the RP is ultimately
 making the decision as to if the user can proceed or not.  Just as in
 SREG if the RP says email is required and the user/OP choose not to
 provide it, the RP still has to decide what to do.

 I do agree that it is easier on a RP to not have to understand any
 relationships between policies.  In this case of the three defined
 policies I see that as less important, but the argument that it
 becomes increasingly likely that the RP may not understand a given
 policy created by an OP is quite legit.  Also as you argue, the OP
 knows what actually happened so can best place that within the  
 policies.

 I'm alright changing the recommendation to the OP at least including
 the specific policies requested by the RP and shifting some of that
 burden back to the OP.  That also is in line with general OpenID
 philosophy of making the OP do the heavy lifting.

 Barry, I was talking to you about this yesterday, you alright with
 this as well?

 In any-case, lets get Draft 2 out in the next 2-3 hours.

 Thanks,
 --David

 On Oct 23, 2007, at 10:05 AM, Johnny Bufu wrote:


 +   [...] For example it is recommended that if the OP
 +specified the Multi-Factor Physical Authentication policy
 and the RP
 +requested the Multi-Factor Authentication policy, that the
 RP's
 +requirements were met.

 This puts undue requirements on the RP implementations. As a design
 principle, I believe the goals were to make required effort and
 adoption and as easy as possible for RPs, and have more happening
 on the OP where possible. I would at least complement, if not
 replace, this patch with:

 For example, if the RP requested Multi-Factor and the OP supports
 Multi-Factor Physical, it is recommended that the OP includes both
 policies in the response.

 As I argued on the osis list, the OP is in the best position to
 make judgments about the qualities of its authentication
 mechanisms, and it should respond to the point to the RP's
 requests. What if the RP knows what Multi-Factor means, but has no
 idea (and no interest) in Multi-Factor-Physical?


 Johnny






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


Fwd: [OpenID] Provider Assertion Policy Extension Draft 2 Published

2007-10-23 Thread David Recordon


Begin forwarded message:

 From: David Recordon [EMAIL PROTECTED]
 Date: October 23, 2007 4:39:23 PM PDT
 To: OpenID List [EMAIL PROTECTED]
 Subject: [OpenID] Provider Assertion Policy Extension Draft 2  
 Published
 Reply-To: [EMAIL PROTECTED]

 Hey all,
 Draft 2 of PAPE has now been published.  http://openid.net/2007/10/23/
 provider-asserton-policy-extension-draft-2/

 Cheers,
 --David

 ___
 general mailing list
 [EMAIL PROTECTED]
 http://openid.net/mailman/listinfo/general



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


An OAuth OpenID Extension

2007-10-22 Thread David Recordon
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


Defining PAPE active authentication (WAS: Re: PAPE Extension Specification)

2007-10-22 Thread David Recordon
Agreed with Jonathan here, don't think we need to define a policy URI  
for active.  Rather need to clarify what is meant in section 5.1.
(Optional) If the End User has not actively authenticated to the OP  
within the number
of seconds specified in a manner fitting the requested policies, the  
OP MUST
authenticate the End User for this request.

What about?
Active authentication is defined as the user providing a credential  
to the OP beyond a cookie which passively stores prior authentication  
credentials.

Still don't like that definition, but hopefully a few iterations and  
we'll get there.  Also asking around in the security community if  
there is a definition for this.

--David

On Oct 11, 2007, at 9:33 AM, Johnny Bufu wrote:


 On 8-Oct-07, at 4:56 PM, Jonathan Daugherty wrote:

 # Yep, the idea is for the PAPE spec to define a few generic and
 # agreed upon policies and then RPs and OPs can create others.  Thus
 # if there isn't agreement on a policy, there would be multiple  
 policy
 # URIs.  Same concept as in Attribute Exchange.

 Using policy URIs to indicate certain modes of authentication is a
 fine idea, but that doesn't really address the original issue: the
 spec does not define active (direct) authentication.

 Agreed. PAPE spec should define one such policy that's acceptable  
 for most of the OPs/RPs (and tie auth_age to it), leaving the  
 possibility open for anyone to define other similar policies.

 This could be a bit tricky to specify if there's another parameter  
 involved, but we should be able to come up with a solution.

 Johnny




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


Re: PAPE Extension Specification (part 2)

2007-10-22 Thread David Recordon

On Oct 9, 2007, at 10:08 AM, Jonathan Daugherty wrote:

 Hi all,

 Here are a few more items.

 Section 5.1

   - The spec doesn't specify what should be done in the absence of
 max_auth_age in a PAPE request.  I could assume, but it would be
 easy enough to specify, say, that the OP is to authenticate the
 user at its own discretion.

Works for me.  http://svn.openid.net/diff.php? 
repname=specificationspath=% 
2Fprovider_authentication_policy_extension%2F1.0%2Ftrunk%2Fopenid- 
provider-authentication-policy-extension-1_0.xmlrev=372sc=1


   - In my opinion, the third paragraph for max_auth_age (beginning
 The OP should realize) is implicit.  I think it should be
 removed.

I could be convinced either way.  Personally I lean toward leaving it  
since it provides additional context as to the parameter.  All of  
PAPE is a negotiation dance between the RP and OP, so also inferring  
that a RP may or may not choose to deny access to the user is important.


   - The preferred_auth_policies specification claims, If multiple
 policies are requested, the OP SHALL try to satisfy as many as it
 can.  In terms of language strength, SHALL try is an oxymoron.
 Can we change this to If multiple policies are requested, the OP
 SHOULD satisfy as many as possible?

Good catch.  http://svn.openid.net/diff.php? 
repname=specificationspath=% 
2Fprovider_authentication_policy_extension%2F1.0%2Ftrunk%2Fopenid- 
provider-authentication-policy-extension-1_0.xmlrev=372sc=1

   - The preferred_auth_policies specification also states that If no
 policies are requested, the RP is interested in other information
 such as the authentication age.  I think that is speculative and
 should be removed.  If it isn't removed, I think it should be
 moved to a section discussing the protocol flow more generally.


I've moved it down under the Value: line which is where most other  
notes are.  If there is somewhere else to put it entirely that is  
good too.  Been trying to augment the parameters with a note so that  
it is easy to get context all in one place.  http://svn.openid.net/ 
diff.php?repname=specificationspath=% 
2Fprovider_authentication_policy_extension%2F1.0%2Ftrunk%2Fopenid- 
provider-authentication-policy-extension-1_0.xmlrev=374sc=1

Thanks,
--David

 Thanks,

 -- 
   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: Question about PAPE

2007-10-22 Thread David Recordon
Hey Siddharth,
Just to be clear, a OTP hardware token is considered a one-time  
password device token not a Hard token given SP 800-63, section 6  
on page 15.  This means that a OTP device can satisfy up to level 3,  
though a FIPS compliant Hard token would be needed for level 4.

Level 3 also requires two-factor authentication, so OTP plus at least  
a password or pin.  On page 37, it gives the example of a one-time  
password device combined with a Level 1 password transmitted via TLS.

When replying with a NIST level, the OP can only include one value.   
Thus if 0, 1, 2 and 3 are possible, the OP should decide which level  
it wishes to respond with.  While 3 may be the strongest, there may  
be situations where you instead want to respond with a lower values.

Yes, per the PAPE abstract it does not talk about enrollment or  
identity proofing.

--David

On Oct 12, 2007, at 3:36 PM, Bajaj, Siddharth wrote:


 Hi David,

 I have a quick question about the PAPE draft specification. In the
 response parameters, you can set a parameter called
 'openid.pape.nist_auth_level'

 There is a section 7.1.2 that describes the paramter and in the last
 table the spec maps some of the common authentication technologies to
 the NIST levels.

 Now for example, lets take an OTP hardware token, which satisfies the
 requirements for Levels 1, 2, and 3. So, should the OP set the  
 value of
 the parameter to the highest level that it satisfies (in this case  
 3) or
 does the OP individually list all the auth levels it meets (in this  
 case
 1,2,3). This is not clear From the table or the spec. Given that the
 barcelona interop is coming up, can you clarify.

 Also, the NIST levels typically take into account the authentication
 credential as well as id proofing. I'm guessing that for the  
 purposes of
 PAPE we are ignoring the initial ID vetting/id proofing requirements.
 Thanks,

 Siddharth


 ___
 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: Defining PAPE active authentication (WAS: Re: PAPE Extension Specification)

2007-10-22 Thread David Recordon
Hey Paul,
How do you guys define passive.  Seems like the opposite problem of  
defining active.

Thanks,
--David

On Oct 22, 2007, at 3:18 PM, Paul Madsen wrote:

 SAML 2.0 expresses it in terms of whether or not the authentication  
 is 'passive'

 paul

 David Recordon wrote:
 Agreed with Jonathan here, don't think we need to define a policy  
 URI  for active.  Rather need to clarify what is meant in  
 section 5.1.
  (Optional) If the End User has not actively authenticated to the  
 OP  within the number
  of seconds specified in a manner fitting the requested policies,  
 the  OP MUST
  authenticate the End User for this request.

 What about?
  Active authentication is defined as the user providing a  
 credential  to the OP beyond a cookie which passively stores prior  
 authentication  credentials.

 Still don't like that definition, but hopefully a few iterations  
 and  we'll get there.  Also asking around in the security  
 community if  there is a definition for this.

 --David

 On Oct 11, 2007, at 9:33 AM, Johnny Bufu wrote:


 On 8-Oct-07, at 4:56 PM, Jonathan Daugherty wrote:


 # Yep, the idea is for the PAPE spec to define a few generic and
 # agreed upon policies and then RPs and OPs can create others.   
 Thus
 # if there isn't agreement on a policy, there would be multiple   
 policy
 # URIs.  Same concept as in Attribute Exchange.

 Using policy URIs to indicate certain modes of authentication is a
 fine idea, but that doesn't really address the original issue: the
 spec does not define active (direct) authentication.

 Agreed. PAPE spec should define one such policy that's  
 acceptable  for most of the OPs/RPs (and tie auth_age to it),  
 leaving the  possibility open for anyone to define other similar  
 policies.

 This could be a bit tricky to specify if there's another  
 parameter  involved, but we should be able to come up with a  
 solution.

 Johnny





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




 -- 
 Paul Madsen e:paulmadsen @ ntt-at.com
 NTT p: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


Some PAPE Wording Clarifications

2007-10-22 Thread David Recordon
Hey Johnny and Jonathan,
Just checked in some clarifications, review would be appreciated.   
http://openid.net/pipermail/commits/2007-October/000381.html

Thanks,
--David

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


SVN URLs Changed

2007-10-08 Thread David Recordon
Hey all,
We're currently in the process of changing all of the SVN URLs to be  
in the form of http://svn.openid.net/.  New URLs are:

http://svn.openid.net/ - WebSVN
http://svn.openid.net/repos/website/
http://svn.openid.net/repos/specifications/

Sorry for the change,
--David

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


HTML-Based Discovery with OP Identifiers

2006-12-28 Thread David Recordon

Sitting here in Seattle with Drummond and looking through the spec.  Section
7.3.3 says:
  HTML-based discovery MUST be supported by Relying Parties.  HTML-
  based discovery is only usable for discovery of Claimed Identifiers.
  OP Identifiers must be XRIs or URLs that support XRDS discovery.

That is a bit confusing to parse so we were looking at re-wording it.  Issue
is Claimed Identifier is defined as possibly being a User-Supplied
Identifier which in turn can be an OP Identifier thus making this
paragraph fall apart.  This then brought up the question of why can't
HTML-Based Discovery be used for OP Identifiers?

So the reason here is that the link elements don't actually describe the
protocol version, rather the OP Endpoint URL and OP-Local Identifier.  This
thus presented us with the problem of how do we version these elements;
which we did via openid. vs openid2..

Does it actually make more sense to add a new link element for the protocol
version?  This means we don't need the kludgey openid2.x as well as allows
support for OP Identifiers.  Thus we could have:
  link rel=openid.provider href=OP Endpoint URL /
  link rel=openid.ns href=http://openid.net/server/2.0; /

-or-

  link rel=openid.provider href=OP Endpoint URL /
  link rel=openid.ns href=http://openid.net/signon/2.0; /

So a parallel to the openid.ns parameter within the messages themselves.

Thoughts?

--David (and Drummond too)

sending from gmail since VPN won't connect :-\
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs