Re: [OIDFSC] Request to consider creation of the User Interface Work Group

2009-02-24 Thread Dick Hardt

+1 (not sure if I am still on the council or not though :-)

On 23-Feb-09, at 11:39 AM, David Recordon wrote:


+1

On Feb 20, 2009, at 6:19 PM, Allen Tom wrote:


Hi Specs Council,

Please consider the attached proposal to form the User Interface  
Work Group.

http://wiki.openid.net/OpenID-User-Interface-Work-Group-Proposal


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


   Name

OpenID User Interface Working Group


   Background Information

OpenID traditionally requires the Relying Party to redirect the  
entire browser window to the OpenID Provider for the user to  
authenticate before redirecting the browser back to the Relying  
Party. It is believed that the User Experience (UX) could be  
significantly improved if the authentication flow occurred within a  
smaller popup window, making the experience less disruptive to the  
user.
Although it is possible for Relying Parties to open a popup window  
for the user to authenticate at the OpenID Provider using the  
Provider's default user interface, the overall user experience can  
be optimized if the OP was aware that its UI was running within a  
popup. For instance, an OP may want to resize the popup browser  
window when using the popup interface, but would probably not want  
to resize the full browser window when using the default redirect  
interface. Another optimization is that the OP can close the popup,  
rather than return a negative assertion if the user chooses to  
cancel the authentication request.
Users who begin the OpenID sign in process on a Relying Party in  
one language and then transition to their OpenID Provider's site in  
a different language may find the overall experience to be very  
disruptive. In many cases, the Relying Party may want to pass a  
language hint to the OpenID Provider to use to display the User  
Interface to the user, especially if the user is not already  
authenticated at the OP.




   Statement of Purpose

This workgroup intends to produce a very brief OpenID extension to  
enable the OpenID Authentication User Interface to be invoked in a  
standalone popup window, and to allow the Relying Party to request  
that the user interface be displayed in a particular language.




   Scope

Produce an extension that allows an OpenID Provider to indicate its  
support of a popup friendly user interface, as opposed to the  
default user interface optimized for a full browser window. The  
popup must be in an independent browser window, and must not be  
framed by the RP.


The extension will also define a mechanim for RPs to pass a  
language hint to the OP to help determine the langange used to  
display the OpenID Authentication user interface.




   Out of Scope
The content of the user interface other than the language that the  
interface is displayed in is out of scope.




   Specifications
OpenID User Interface Extension 1.0

   Anticipated audience

All those interested in improving OpenID Usability.

   Language of business

English.

   Method of work

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


   Basis for completion of the activity

The OpenID User Interface Extension 1.0 final draft is completed.

   Proposers

 * Allen Tom, a...@yahoo-inc.com, Yahoo!
 * Brian Ellin, br...@janrain.com, Janrain
 * David Recordon, da...@sixapart.com, Six Apart
 * Chris Messina, ch...@citizenagency.com, Vidoop/DiSo Project*  
Breno de Medeiros, br...@google.com, Google

 * Luke Shepard, lshep...@facebook.com, Facebook


   Initial Editors

 * Allen Tom, a...@yahoo-inc.com, Yahoo!
 * Breno de Medeiros, br...@google.com, Google






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


RE: Suggested scoping for AX 2.0 WG

2009-02-04 Thread Dick Hardt

To be clear, what I have suggested is not the bulk exchange of multiple users. 
It is the method to treat number of attributes as a group that requires some 
integrity within them. When it comes to CX, by design, it does not do multi 
user exchane either since it requires the parties to explicitly sign the 
contract.


The advantage of keeping it in this WG is that we make sure that different 
approaches to handling exchange of user attributes are viewed by the same 
people, even if it ends up in a separate mini-spec.

The counter-argument is that most members of this WG are not interested 
primarily in this functionality, and it may distract both efforts (CX and AX), 
and that AX is unlikely to directly support anything along these lines.


I think that Nat’s description above is a general requirement and makes sense 
to be in scope.
To clarify, bulk movement of attributes from different users is not in scope – 
grouping attributes together would be in scope (I’m interested in this 
functionality)

Anyone have a concern with that?


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


Suggested scoping for AX 2.0 WG

2009-02-03 Thread Dick Hardt
1) I'd prefer to NOT include SREG in the work, but am ok with it being in if 
the scope is really to clarify issues in SREG and add language directing people 
to AX. Anyone else have a strong opinion either way? (SREG included in this WG 
or in a different one?)

2) In the Scope section, I feel strongly that bulk exchange of attributes about 
multiple users is out of scope. It is a very different design pattern then what 
AX does now. I have not seen the background on why this is in scope, so perhaps 
I can have a different view if someone cares to enlighten me.

-- Dick

PS: please use my microsoft.com address for any specs discussions.

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


RE: Suggested scoping for AX 2.0 WG

2009-02-03 Thread Dick Hardt
Thanks for the feedback Breno!

Nat: can you provide some illumination? I see that CX would define attribute 
types to be carried in AX. I'm confused about the scenario where information 
from multiple users would be transmitted as that implies that the protocol no 
longer is dealing with a single subject.

-Dick

From: Breno de Medeiros [mailto:br...@google.com]
Sent: Tuesday, February 03, 2009 2:39 PM
To: Dick Hardt
Cc: da...@sixapart.com; Allen Tom; Martin Atkins; Nat Sakimura; OpenID Specs 
Mailing List
Subject: Re: Suggested scoping for AX 2.0 WG


On Tue, Feb 3, 2009 at 2:19 PM, Dick Hardt 
dick.ha...@microsoft.commailto:dick.ha...@microsoft.com wrote:
1) I'd prefer to NOT include SREG in the work, but am ok with it being in if 
the scope is really to clarify issues in SREG and add language directing people 
to AX. Anyone else have a strong opinion either way? (SREG included in this WG 
or in a different one?)

I'm ok either way.


2) In the Scope section, I feel strongly that bulk exchange of attributes about 
multiple users is out of scope. It is a very different design pattern then what 
AX does now. I have not seen the background on why this is in scope, so perhaps 
I can have a different view if someone cares to enlighten me.

When Nat Sakimura wrote the contract exchange CX proposal, he included scope 
for exchanging validation/metadata about attributes, and it was felt that it 
should belong here. CX also needs this bulk exchange functionality and again 
because it pertained to attributes, it was believed that it would better fit 
here.

The advantage of keeping it in this WG is that we make sure that different 
approaches to handling exchange of user attributes are viewed by the same 
people, even if it ends up in a separate mini-spec.

The counter-argument is that most members of this WG are not interested 
primarily in this functionality, and it may distract both efforts (CX and AX), 
and that AX is unlikely to directly support anything along these lines.




-- Dick

PS: please use my microsoft.comhttp://microsoft.com address for any specs 
discussions.



--
--Breno

+1 (650) 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)
___
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-27 Thread Dick Hardt
I'd prefer to narrow the scope of the WG and keep it focussed on a  
small number of goals.


A separate WG on SREG would be preferred, but I think it is a  
disservice to the community to have two specs having such significant  
overlap.
Choice in this case leads to confusion and reluctance to invest. The  
challenge is that those with an investment in SREG now have a  
propensity to see it continue on even though intellectually they can  
see the advantage of a unified spec.


fwiw: I am in an off-site most of this week and won't be able to  
engage significantly until next week.


-- Dick

On 26-Jan-09, at 9:34 PM, Breno de Medeiros wrote:


Let's please maintain the discussion on this thread on definition of
the scope of the WG. Once the WG is formed, the technical aspects can
be discussed there.

The only pertinent issue that is left open in this regard appears to
be whether or not SREG will be inspected as part of this. Allen,
please edit the WG proposal charter to include it.

On Mon, Jan 26, 2009 at 9:25 PM, Raghu Nallani Chakravartula
ra...@producthorizons.com wrote:
Futher, the verification information cannot sometimes be expressed  
in a

single type.
It may need to be qualified with additional information as regards  
who

verified it, when, how long is the verification valid etc...

I am guessing validation data exchange will need to grow into a  
struct

exchange.

-Raghu

Paul Madsen wrote:


FWIW, the separate 'verified' field is the approach the Infocard  
community

took

https://informationcard.net/wiki/index.php/Claim_Catalog

They also allow the particular verification method used to be listed


https://informationcard.net/wiki/index.php/ 
Claim_Catalog#Verification_Methods


One drawback of this method is that all claims sent together get  
lumped

together into a single bucket wrt verification

paul

Martin Atkins wrote:


Henrik Biering wrote:


Agree!
If the range of SReg attributes is expanded, however, I would  
suggest to
add phone number (incl. quality as suggested for email) and  
possibly
street+city address line(s). That would make it possible to fill  
in a

somewhat larger part of typical registration forms.



It might be good to apply the quality thing to all of the fields.

One approach might be to add a verified argument that contains  
a list

of names of fields that the OP has verified in some way.

However, I think the SREG spec itself needs work done since the  
1.1 draft
(that was never published) has a bunch of problems. It might be  
better to do
such work in a separate working group; I already have an updated  
1.1 draft
with some of the problems from the current 1.1 draft fixed that  
could
potentially be used as a basis, though I'll need to dig it out  
since I'm not

sure what I checked it in to.

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




--
Paul Madsen
e:paulmadsen @ ntt-at.com
p:613-482-0432
m:613-282-8647
web:connectid.blogspot.com
ConnectID http://feeds.feedburner.com/%7Er/blogspot/gMwy/%7E6/1


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



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





--
--Breno

+1 (650) 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)
___
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: Use of Qworum for indirect communication

2008-12-17 Thread Dick Hardt

Designing OpenID around a particular product is clearly a non-starter.

Enabling smart clients was discussed as part of OpenID 2.1 at IIW.

Smart clients can:
 reduce the phishing risk of malicious RPs
improve the user experience by simplifying the flow
improve the performance by reducing the number of HTTP calls.

We will still need to continue to support dumb browsers and hence  
browser redirects and form submission.


-- Dick



On 17-Dec-08, at 7:38 AM, Doğa Armangil wrote:

I think that OpenID auth would benefit from Qworum in a broad sense,  
because Qworum aims to address the needs of a class of services  
called multi-phase services, which includes OP-type services.


Having said that, two concrete benefits immediately come to mind:

1. Simplified OP
Currently the OP does two things: (1) it provides core  
authentication functionality, and (2) it takes care of integrating  
itself into the calling RP by keeping track of the return address.
When Qworum is used, the non-core task (2) is handled by the user  
agent, and the OP can concentrate on providing only the core  
functionality.


2. Robust message semantics
With Qworum, authentication request and response messages are XML  
documents. Needless to say, XML is a mature and powerful messaging  
format. The one benefit of XML that I will mention here is that it  
allows the use of namespaces for qualifying OpenID request  
parameters and response fields (instead of the openid. prefix).  
Example:


message xmlns:openid='http://openid.net/'
  openid:modecheckid_setup/openid:mode
  ...
/message

My general impression regarding the OpenID-Qworum link is that it  
just makes sense.



2008/12/16 David Fuelling sappe...@gmail.com
Cool idea, although I wonder what benefit this would bring to OpenID  
auth?  Seems like HTTP redirects and form submits work pretty well  
today.  Would Qworum enable any sort of new features that aren't  
possible today because we're not using XML between RP/OP/User-agent?


Thanks!

david

2008/12/15 Doğa Armangil doga.arman...@gmail.com
The OpenID Authentication 2.0 specification states in section 5.2  
that There are two methods for indirect communication: HTTP  
redirects and HTML form submission. It is worth noting that a third  
method might be added to this list: Qworum ( http://www.qworum.com/ ).


Qworum is a fairly new technology (a couple of years old) that aims  
to solve precisely the problem of indirect communication between  
interactive web services (such as between Relying Parties and OpenID  
Providers). Qworum mandates that the caller (i.e. RP) and the callee  
(i.e. OP) communicate through XML documents.


Here is one possible authentication scenario involving Qworum:


1. The RP calls the OP by sending the following Qworum message to  
the user agent:


!-- Return to the RP after calling the OP --
qrm:goto href='/auth_complete' xmlns:qrm='http://www.qworum.com/'

  !-- Call the OP --
  qrm:call href='http://openid-provider.net/my_id'

!-- Authentication request message --
message xmlns:openid='http://openid.net/'
  openid:modecheckid_setup/openid:mode
  openid:identityhttp://openid-provider.net/my_id/ 
openid:identity

  ...
/message

  /qrm:call

/qrm:goto

This message instructs the user agent to call the OP and to send the  
result back to the RP.


2. The user agent then calls the OP (i.e. http://openid-provider.net/my_id 
 ) by POSTing it the following XML document:


message xmlns:openid='http://openid.net/'
  openid:modecheckid_setup/openid:mode
  openid:identityhttp://openid-provider.net/my_id/openid:identity
  ...
/message

3. The OP interacts with the end user.

4. The OP sends the following Qworum message to the user agent:

!-- Authentication response message --
message xmlns:openid='http://openid.net/'
  openid:modeid_res/openid:mode
  openid:identityhttp://openid-provider.net/my_id/openid:identity
  ...
/message

5. Finally, the user agent then POSTs the authentication response  
message back to the RP. Note that the RP return address is handled  
by the user agent, not the OP.



Adding Qworum as a third communication method would not break  
existing methods, it would just offer one more choice to RPs:
* The RP can check whether the user agent has Qworum capability by  
inspecting the Accept header of the HTTP request. The RP can then  
choose to use Qworum.
* The OP would understand that the RP is using Qworum to call it if  
the Content-Type of the HTTP POST request is application/xml.


So my question is this: Has Qworum been considered for indirect  
communication, or could it be considered in the future?  (As the  
lead developer of Qworum, I can affirm that Qworum would do all it  
can to facilitate this process.)


--
Doğa Armangil


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





--
Doğa Armangil


Re: What is the status of AX 2.0 WG proposal?

2008-12-17 Thread Dick Hardt

I've been busy with other things. :-)

I had an in person chat with Allen Tom, Eran and Breno about what they  
were thinking of. There was some discussion on the step2 list.


I have a work item to write up the scope so that we can get it started  
-- but have needed to deal with some time critical tasks before I  
could start on it -- sorry.


-- Dick

On 17-Dec-08, at 4:56 PM, Nat Sakimura wrote:


I am very interested in it, but have not heard about it for sometime.

What is the status 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


Re: Could you update me of the status of CX WG proposal?

2008-12-17 Thread Dick Hardt

On 17-Dec-08, at 6:17 PM, Nat Sakimura wrote:

 Hi.

 Could you kindly update me of the status of CX WG proposal?
 People are waiting for it.

 Also, I think it is a really good idea to set up a ML for spec  
 council so that people can mail the spec council collectively.
 I am emailing to David, Dick and Josh just because I happen to have  
 found them easily in my addressbook.
 I wanted to email to the entire spec council, really.

I thought David was going to create a list for spec council.

Nat: I also cc'ed Mike Jones and Johnny -- the other two members of  
the specs council

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


Re: What is the status of AX 2.0 WG proposal?

2008-12-17 Thread Dick Hardt
Breno, if you have time to update the proposal per our discussion that  
would be fabulous!

On 17-Dec-08, at 5:07 PM, Breno de Medeiros wrote:

 We have made significant process in that in-person chat and we need to
 document this in proposal draft form.

 I could try and update the proposal for validate request which has
 tentatively been abandoned in terms of allowing meta-data to describe
 attributes in fetch/store requests.

 2008/12/17 Dick Hardt dick.ha...@gmail.com:
 I've been busy with other things. :-)
 I had an in person chat with Allen Tom, Eran and Breno about what  
 they were
 thinking of. There was some discussion on the step2 list.
 I have a work item to write up the scope so that we can get it  
 started --
 but have needed to deal with some time critical tasks before I  
 could start
 on it -- sorry.
 -- Dick
 On 17-Dec-08, at 4:56 PM, Nat Sakimura wrote:

 I am very interested in it, but have not heard about it for sometime.

 What is the status 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





 -- 
 --Breno

 +1 (650) 214-1007 desk
 +1 (408) 212-0135 (Grand Central)
 MTV-41-3 : 383-A
 PST (GMT-8) / PDT(GMT-7)

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


Re: Completing the SREG 1.1 specification

2008-12-02 Thread Dick Hardt

On 2-Dec-08, at 3:41 PM, Allen Tom wrote:

 We decided to build support for SREG before AX because SREG seems to  
 be
 more widely used, and also because SREG allows the RP to pass the  
 url to
 its privacy policy in the request. Strangely, AX does not have an
 interface for the RP to pass its privacy policy to the OP.

Not sure how we missed that feature in SREG. Our bad.

 Moving forward, we'd also like to support both SREG and AX, if AX is
 updated to allow the privacy policy url to be included in the request.

Looking at what needs to be addressed in AX. Good suggestion. Ties in  
with suggestions from Nat where the response with the privacy policy  
is returned all signed by the OP.



 I'd be happy to help contribute to SREG and AX specs if the owners of
 the spec would like me to.

please!

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


Re: Completing the SREG 1.1 specification

2008-11-29 Thread Dick Hardt

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


Re: Completing the SREG 1.1 specification

2008-11-28 Thread Dick Hardt
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?

-- Dick

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


 Hi all,

 It recently became apparent that version 1.1 of the Simple  
 Registration
 Extension (SREG), which updates the protocol to work as an OpenID
 Authentication 2.0 extension, was never finished and published.

 Furthermore, it has been noted that the latest draft contains
 ambiguities about how SREG is to be used in 1.1 vs. 2.0 messages, and
 that in some cases it does not describe how SREG is used by popular
 implementations today.

 I'd like to form a working group to get version 1.1 completed, with a
 focus on simply writing down what current implementations do to aid
 interoperability rather than making any changes.

 I have a draft of a more formal working group proposal prepared, but
 first I'd like to see who is interested in working on this. The  
 minimum
 membership for an OpenID Foundation working group is five members. I
 anticipate that this group's work will be done relatively quickly,  
 since
 we'd merely be documenting established practice.

 Please reply here if you'd be interested in joining this working  
 group,
 and in particular whether you are willing to be listed as a proposer  
 in
 the working group proposal.

 I have included below my current draft working group proposal. I  
 welcome
 any comments on it.

 Thanks,
 Martin

 

 OpenID Authentication 2.0 was finalized this past December and since
 has started to see quite reasonable adoption. Many implementations
 of Authentication 2.0 have made use of the Simple Registration
 Extension that was popularized as an ad-hoc OpenID 1.1 extension.

 While SREG is compatible with and has been deployed using the more
 formal extension mechanism described in OpenID Authentication 2.0,
 a 2.0-compatible version of SREG was never published. A draft
 revised version is available [1], but it was never approved as
 a specification and contains some ambiguities about how SREG
 is used in 2.0 vs 1.1 messages.

 This proposal is to form a working group to finish and publish
 a version of SREG that is compatible with OpenID Authentication 2.0,
 describing how SREG is used in existing popular implementations.

 

 == Background information ==
 Many implementors have extrapolated how SREG 1.0 can be used within
 the extension mechanism defined in OpenID Authentication 2.0, but
 this has actually never been documented in a specification. A draft
 of SREG 1.1 was produced[1], but it was not published and has been
 found to contain some ambiguities and deviations from established
 practice.

 == Working Group Name ==
 OpenID Simple Registration Extension 1.1

 == Purpose ==
 To complete and publish the SREG 1.1 specification, documenting
 how SREG is used by popular implementations today.

 == Scope ==
 The proposed work is as follows:
 * Update the SREG specification to describe how it can be used as
 an OpenID 2.0 extension as well as an OpenID 1.1 ad-hoc extension.
 * Update the SREG specification to correct any deviations between
 the specification and established implementation practice.

 Note that this charter does not include adding new features to
 Simple Registration; ideally, the specification produced by this
 working group will merely be documenting existing implementation
 practice, and will require no changes to existing implementations
 as far as possible. Where implementations differ, an approach
 will be chosen on the basis of number of deployments and on
 consensus within the working group.

 == Anticipated Contributions ==
 * Feedback from library authors and other implementors about
 how they have adapted SREG 1.0 to work within OpenID 2.0's
 extension mechanism.
 * Specification text to achieve the the goals described in
 the above scope.

 == Proposed List of Specifications ==
 * OpenID Simple Registration Extension 1.1 (SREG 1.1)

 == 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 ==
 Work will take place primarily on the working group mailing list,
 with the possibility of conference calls and face-to-face meetings
 if deemed necessary by the working group.

 == 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:
 * Martin Atkins, Six Apart ([EMAIL PROTECTED])
 * David Recordon, Six Apart ([EMAIL PROTECTED])
 * ...

 Initial Editors:
 * Martin Atkins, Six Apart ([EMAIL PROTECTED])
 * David Recordon, Six Apart ([EMAIL 

Re: Proposing an OpenID Authentication 2.1 Working Group

2008-11-18 Thread Dick Hardt

Excellent point about moving to a standard library for XRD Chris!

On 18-Nov-08, at 7:07 AM, Chris Messina wrote:

And given the growing momentum with the new-fangledness (and it's  
use in other places like OAuth and Portable Contacts and OpenSocial)  
it would be nice if, by the time an initial draft of the newness is  
complete, OpenID would be ready with support for it, so that we can  
simplify and minimize the number of libraries out there (i.e. ONE  
set of discovery libraries).


I also appreciate Martin's notes from IIW, since I was unable to  
attend, and look forward to David's new charter, since I'm very much  
in favor and supportive of this work!


Chris

On Wed, Nov 12, 2008 at 6:06 PM, Dick Hardt [EMAIL PROTECTED]  
wrote:

Eran is promising to move the XRD spec forward quickly.

-- Dick

On 12-Nov-08, at 3:01 PM, Joseph A Holsten wrote:

 Feel free to  focus on yadis/xrds errata, but don't worry about XRD
 new fangledness yet. I'd even say don't mention xrds-simple. OpenID
 has been workable with yadis/xrds. But until the xrds-simple/xrd
 stuff gets near final, mentioning it will only confuse people and
 strain their trust.

 http://josephholsten.com

 On Nov 11, 2008, at 2:46 PM, David Recordon wrote:

 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


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

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



--
Chris Messina
Citizen-Participant 
 Open Technology Advocate-at-Large
factoryjoe.com # diso-project.org
citizenagency.com # vidoop.com
This email is:   [ ] bloggable[X] ask first   [ ] private


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


Re: Proposing an OpenID Authentication 2.1 Working Group

2008-11-12 Thread Dick Hardt
Eran is promising to move the XRD spec forward quickly.

-- Dick

On 12-Nov-08, at 3:01 PM, Joseph A Holsten wrote:

 Feel free to  focus on yadis/xrds errata, but don't worry about XRD
 new fangledness yet. I'd even say don't mention xrds-simple. OpenID
 has been workable with yadis/xrds. But until the xrds-simple/xrd
 stuff gets near final, mentioning it will only confuse people and
 strain their trust.

 http://josephholsten.com

 On Nov 11, 2008, at 2:46 PM, David Recordon wrote:

 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


 ___
 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: Auto logout? Request re-authentication from the server?

2008-07-02 Thread Dick Hardt
One parameter of PAPE was allowing the RP to specify how long it had  
been since the OP had authenticated the user.

There is a PAPE working group right now, if you were interested in  
looking at how your suggestions would be incorporated, I am sure they  
would welcome you to the group.

I've cc'ed Mike Jones who is one of the people driving PAPE

-- Dick

On 2-Jul-08, at 7:45 AM, Simon Josefsson wrote:

 Hi.

 Is there a best practice on how Openid consumers can find out whether
 re-authenticating the user, via the OpenID server, once in a while can
 lead to improved security?

 The security of normal one-time password systems (SecurID, SMS codes,
 Yubikeys, ..) can be improved if you ask for a new one-time password
 once in a while.

 Of course, the OpenID server cannot do this on its own, so it needs to
 be initiated by the OpenID consumer, but that will not happen without
 clues that it is a good idea to do perform re-authentication.

 Thoughts?

 Would this be a worthwhile addition to the
 openid-provider-authentication-policy-extension document?  I'm  
 thinking
 that the Response Parameters should include an optional parameter that
 imply that a one-time-password system was used, which suggests that  
 the
 RP may re-authenticate the user more frequently.

 It may be useful to generalize this idea somewhat, but I can't come up
 with a better abstraction.  Even re-authenticating using password may
 improve security in some situations (although I suspect most passwords
 are cached by browsers anyway these days).  Ideas welcome.

 Thanks,
 Simon

 Btw, this idea originated from discussions on
 http://forum.yubico.com/viewtopic.php?f=9t=126.
 ___
 specs mailing list
 specs@openid.net
 http://openid.net/mailman/listinfo/specs

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


RECOMMENDED: Proposal to create the PAPE working group

2008-05-22 Thread Dick Hardt
The specifications council recommends that the Foundation members  
approve the creation of the Provider Authentication Policy Extension  
(PAPE) working group, as proposed below.


-- Dick

On 22-May-08, at 3:25 PM, Mike Jones wrote:

This message is being sent to revise the proposal to create the PAPE  
working group, changing only one word, so that the projected  
completion date is July 2008, rather than May 2008.  The complete  
text of the revised proposal follows.


--- Mike

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:  Provider Authentication Policy  
Extension (PAPE)
(ii)  Purpose:  Produce a standard OpenID extension  
to the OpenID Authentication protocol that:  provides a mechanism by  
which a Relying Party can request that particular authentication  
policies be applied by the OpenID Provider when authenticating an  
End User and provides a mechanism by which an OpenID Provider may  
inform a Relying Party which authentication policies were used. Thus  
a Relying Party can request that the End User authenticate, for  
example, using a phishing-resistant and/or multi-factor  
authentication method.
(iii)  Scope:  Produce a revision of the PAPE 1.0  
Draft 2 specification that clarifies its intent, while maintaining  
compatibility for existing Draft 2 implementations.  Adding any  
support for communicating requests for or the use of specific  
authentication methods (as opposed to authentication policies) is  
explicitly out of scope.
(iv)  Proposed List of Specifications:  Provider  
Authentication Policy Extension 1.0, spec completion expected during  
July 2008.
(v)  Anticipated audience or users of the work:   
Implementers of OpenID Providers and Relying Parties – especially  
those interested in mitigating the phishing vulnerabilities of  
logging into OpenID providers with passwords.
(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 a face-to-face meeting at the Internet Identity Workshop.
(viii)  Basis for determining when the work of the  
WG is completed:  Proposed changes to draft 2 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 in other WGs or  
organizations:  (1) Assurance Levels as defined by the National  
Institute of Standards and Technology (NIST) in Special Publication  
800-63 (Burr, W., Dodson, D., and W. Polk, Ed., “Electronic  
Authentication Guideline,” April 2006.) [NIST_SP800‑63].  This  
working group is needed to enable authentication policy statements  
to be exchanged by OpenID endpoints.  No coordination is needed with  
NIST, as the PAPE specification uses elements of the NIST  
specification in the intended fashion.

(ii)  Proposers:
Michael B. Jones, [EMAIL PROTECTED],  
Microsoft Corporation
David Recordon,  
[EMAIL PROTECTED], Six Apart Corporation
Ben Laurie, [EMAIL PROTECTED], Google  
Corporation
Drummond Reed, [EMAIL PROTECTED] 
, Cordance Corporation
John Bradley,  
[EMAIL PROTECTED], Wingaa Corporation
Johnny Bufu, [EMAIL PROTECTED],  
Independent
Dick Hardt, [EMAIL PROTECTED],  Sxip  
Identity Corporation

Editors:
Michael B. Jones, [EMAIL PROTECTED],  
Microsoft Corporation
David Recordon,  
[EMAIL PROTECTED], Six Apart Corporation

(iii)  Anticipated Contributions:  None.

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


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


Re: Using email address as OpenID identifier

2008-04-02 Thread Dick Hardt


On 1-Apr-08, at 11:15 PM, Paul E. Jones wrote:


Dick,

I’ll give you that one: that’s certainly easier.  But, does not  
cause some confusion?  After all, one’s identity is not yahoo.com,  
but that is the identity provider.  Perhaps the prompts around the  
Internet ought to Say “OpenID Provider:” instead? :-)


:-) ... that label would be more accurate. There is lots of work to be  
done to make OpenID simpler for users. I think that what will be easy  
for users is something provided by the browser that lets the user  
click to initiate a login or registration. No typing is better then  
any typing! Back when we started working on the protocols we could not  
expect this kind of functionality to be in the browsers. Now that  
awareness is higher, having it built into the browser is feasible. I  
of course am biased given the work we have done with Sxipper http://sxipper.com 
 :)




Presently, this variant works form some providers, but not most.  I  
assume it’s due to the fact they’re not fully compliant with the  
spec yet? Or, is there some confusion as to how this ought to work?


I don't think an OP is not OpenID 2.0 compliant if it does not take  
the OP as an identifier -- but I would have to reread to the spec to  
make sure.


-- Dick



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


Re: OpenID and Yahoo

2008-04-02 Thread Dick Hardt

On 2-Apr-08, at 6:28 AM, McGovern, James F (HTSC, IT) wrote:
 Does anyone have a perspective on Yahoo and AOL and their weak support
 for OpenID? It is good that they are a provider, but shouldn't they
 really also allow access based on an OpenID issued by signon.com,
 myvidoop.com and others...

I would be much more interested in them supporting Attribute Exchange  
so that their users data could easily be consumed by other sites.

This topic was recently covered by TechCrunch[1] and I responded [2]

-- Dick

[1] 
http://www.techcrunch.com/2008/03/24/is-openid-being-exploited-by-the-big-internet-companies/

[2] http://identity20.com/?p=147



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


Re: Using email address as OpenID identifier

2008-04-01 Thread Dick Hardt


On 1-Apr-08, at 7:37 PM, Brad Fitzpatrick wrote:


-- that said, with directed identity in OpenID 2.0, a user just  
needs to type in yahoo.com, or press the pretty yahoo button.  No  
typing.


I think this is why we don't need to use emails. People are very  
familiar with typing in a URL in the address bar. The experience of  
entering an URL and then being on that page is also really familiar.  
This is of course what happens when you type the OP into the OpenID  
prompt.


Sorry for not being the least bit supportive of the email as  
identifier idea -- there are just so many things that are bad about it  
and the good reason (an identifier they already know) is provided per  
above with the advantage of giving an expected experience.


I agree with Brad that we need to write a FAQ on this.

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


Re: Using email address as OpenID identifier

2008-04-01 Thread Dick Hardt

Entering yahoo.com is even easier!

On 1-Apr-08, at 10:05 PM, Paul E. Jones wrote:


Eran,

I’m not suggesting that the address must be a real e-mail address.   
I’m suggesting that the ID has that form.  It’s easier for users  
than enteringhttps://me.yahoo.com/userid.  If it happens to also be  
one’s real e-mail address, fine.  That would be a plus for me, but I  
don’t see that as a requirement.


Paul


From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On  
Behalf Of Eran Hammer-Lahav

Sent: Wednesday, April 02, 2008 12:17 AM
To: specs@openid.net
Subject: RE: Using email address as OpenID identifier

Take a look at http://www.hueniverse.com/hueniverse/2008/01/addressing-open.html 
 - especially the list of other solutions proposed before me, as  
well as Brad’s proposal.


The thing is, you need the @gmail, @hotmail, @msn, @yahoo, @aol to  
support this DNS, and they *are* the email providers.


EHL

From: Paul E. Jones [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 01, 2008 11:42 PM
To: Eran Hammer-Lahav; specs@openid.net
Subject: RE: Using email address as OpenID identifier

Eran,

You’re entirely correct that this is not an OpenID issue, per se.   
In fact, not a single word of text would need to be changed in the  
current v2 specs, as far as I’m concerned.


But, I do think that it will take some of the core OpenID team  
members to put a stake in the ground and say, “this is the  
convention that we’ll follow.”  What needs to happen then is perhaps  
an extension written that explains how to convert an email address  
to a URL.  Using NAPTR records seems like the simplest way to do it  
to me, but I’m open to suggestions.


Perhaps it is important to say, though, that I do not think it  
requires the e-mail providers to get on board with this (in my view)  
simpler notation.  I could use an ID like [EMAIL PROTECTED] and  
that should work, if myopenid.com would publish the appropriate  
NAPTR record.  I could also insert NAPTR records into the  
packetizer.com DNS server that would allow me to use my email  
address, but point at my preferred OpenID provider.  In short, just  
because the [EMAIL PROTECTED] syntax is used does not mean that it  
necessarily an e-mail address: it could be, but more importantly, it  
just follows that familiar format documented in RFC 822.


Paul

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On  
Behalf Of Eran Hammer-Lahav

Sent: Tuesday, April 01, 2008 10:43 PM
To: specs@openid.net
Subject: RE: Using email address as OpenID identifier

The beauty of the current OpenID spec is that anyone can implement  
it and go live. However, with email identifiers you need email  
providers to support it. If Google, Yahoo, AOL, or Microsoft  
announced they are adding such a feature, I am sure the others are  
likely to follow. Get 2 of these 4 and you’ve got something going.  
But the biggest issue is not picking a standard but finding a  
company willing to put something out there.


As for the technical solutions, there are many from DNS to XRDS to a  
simple template agreed by all. Brad Fitzpatrick argued at FooCamp  
that this is not an OpenID issue, but a non-HTTP URI -- HTTP URI  
conversation. Basically if you had a generic way of moving  
frommailto:[EMAIL PROTECTED] to http://example.com/url/user (or any  
other URI with HTTP, the domain, and the user), any URI can be used  
for OpenID.


But at the end this is about someone of a major email provider  
saying they are interested and put out something people can use.  
After that I expect the snowball to roll. So, do you know anyone? J


EHL

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On  
Behalf Of Paul E. Jones

Sent: Tuesday, April 01, 2008 10:31 PM
To: specs@openid.net
Subject: Using email address as OpenID identifier

Folks,

I’ve seen discussion here and there on the use of the e-mail address  
as the OpenID identifier.  Perhaps this one says it best:

http://www.majordojo.com/2007/02/what-openid-needs.php

I share many of same opinions.  If OpenID is going to be practically  
usable by the average person, we cannot require the person to  
remember some very complex identifier.  When I signed up for Yahoo’s  
OpenID service, it presented me with a hideously ugly URL that  
looked similar to a base64-encoded string.  I could not begin to  
tell you what it was.  Fortunately, Yahoo allowed me to define my  
own, friendlier name.  Still, the ID is not one that the average  
user will remember or get right.


While the e-mail address does not have to be the one’s ID, it can  
certainly serve as an alias.  Suppose, for example, that the DNS  
records at Yahoo contained the following entry:


  yahoo.com. IN NAPTR 100 10 U OpenID2 ^(.+)@(.*)$!https://me.yahoo.com/ 
\1!i


This would allow a Relaying Party to accept an e-mail address and  
perform a simple transformation to get the “real” URL identifier.   
Of course, this does not mean that the existing URL or XRI  
identifiers are invalid, nor does it 

Re: Using email address as OpenID identifier

2008-04-01 Thread Dick Hardt


On 1-Apr-08, at 10:02 PM, Paul E. Jones wrote:


Dick,

On this point, I really have to disagree.  Even I rarely enter a URL  
into a web browser. Why bother when I know the web browser will  
figure it out for me.  I don’t want to type http:// or https:// :-)


I don't want to type the protocol either. I should have been more  
clear, the user types yahoo.com or aol.com into the prompt. Since this  
is NOT the identifier (which is a useful aspect of this method) -- the  
risks of NOT using https are much lower.


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


Re: RP generated nonce for stateful mode.

2007-11-20 Thread Dick Hardt
You point out the issue. A hash of the session-id is NOT a nonce. A  
nonce is required to prevent replay attacks.

-- Dick

On 19-Nov-07, at 8:19 PM, NISHITANI Masaki wrote:

 Hi everyone.

 OpenID 2.0 uses nonce generated by OP to identify the
 transaction. This seems very reasonable for stateless mode
 authentication, because OP is the entity which is
 responsible for protecting the stateless mode transaction
 from replay-attacks. In this case, it is not so difficult
 for OP to control nonce not to be used twice.

 On the other hand, for stateful mode, OP generated nonce is
 also used and RP assures the nonce should be uses only once
 this time.
 In general, it costs more for someone other than the
 generator to ensure using nonce once, than the genetator
 itself does it. Also in this case, RP should remenber every
 nonces during certain time referring timestamp on each nonce.

 Using RP generated nonce could simplify this. For example,
 RP only caliculate a hash value for the end-users session-id
 and send this to OP in auth_req. Then OP signs to the
 RP-genetated-nonce and send it back in auth_res, now RP can
 verify the sign with the session-id very easily. RP and OP
 do not need to remember nonces.

 Of cource this is not a nonce in strict meaning, and can be
 used more than once. But that parameter is valid only in the
 end-user's session. So if someone want to use the value for
 replay-attack, it should hijacks the session beforehand.

 So I wonder if this kind of idea has been discussed before
 or not, and if it has.
 ___
 specs mailing list
 specs@openid.net
 http://openid.net/mailman/listinfo/specs



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


Re: OpenID 2.0 finalization progress

2007-10-25 Thread Dick Hardt
I don't see anyone not ready to make non-assertion statements about  
the specs.
I have stated that Sxip would make non-assertions on OpenID  
Authentication 2.0 and OpenID Attribute Exchange once they are BOTH  
proposed to be Final.

Creating a complete IPR process going forward is what is also being  
proposed. Essentially the OpenID Foundation is becoming a standards  
body. This is a significant shift in the OpenID Foundation Charter,  
as the charter explicitly states that creating specifications is out  
of scope of the Foundation. This change is NOT something that can be  
done quickly.

(have you looked over the IPR Process and Policy documents Brad?)

-- Dick

On 23-Oct-07, at 11:50 AM, Brad Fitzpatrick wrote:

 I see no need to rush OpenID 2.0 if the parties involved here on this
 mailing list can't even commit to not sue each other.  Seems like a
 no-brainer to me.

 Yes, maybe some third-party has a patent and can assert it later, but
 let's at least say amongst ourselves, in the form of an IPR policy,
 that we have no patents on this stuff and/or won't assert them against
 anybody in the future using them for OpenID.  Or whatever best  
 practices
 are for IPR policies.

 No need for a lengthy patent search.  We could do that later.  I'm  
 sure
 we'll just find a bunch of trivial patents covering all sorts of  
 OpenID
 stuff anyway.  But the point is: those all have their own histories  
 of why
 they were obtained, their assertion policies, etc.

 If OpenID 2.0 is stamped complete without an IPR non-assertion  
 statement
 from everybody involved here, I'm going to blog red flags far  wide
 because I see no reason this little crew can't get that much  
 together in
 time, and quite quickly.

 - Brad


 On Mon, 22 Oct 2007, Dick Hardt wrote:


 On 19-Oct-07, at 10:20 PM, David Recordon wrote:

 Completely agreed with Johannes.  We are very close with the IPR
 policy/process being in place and assuming all the contributors  
 agree
 to it, 2.0 can be declared final within 30 days of October 30th as
 that is the end of the public review period for the policy.  2.0 is
 really important and has a wide range of contributors, we've all put
 a lot of effort into this, lets make sure we do this right.

 Doing it right would have been to have had a process in place over a
 year ago. A little late to be doing it right now. Now we are having
 to clean up the mess!


 To Kevin's question, the IPR policy does not require a patent  
 search,
 which as he points out could be a lengthy process.  Rather it
 requires that all contributors to the specification make a non-
 assertion statement to ensure that the spec truly is free and not
 encumbered by any patents.

 Just because the contributors all make non-assertion statements does
 not make the spec unencumbered. Non-contributors could have patents
 that are asserted.

 While having an IPR policy in place will, provide more certainty
 around the IPR, it will NOT ensure the spec is free.


 I spoke with Brad Fitzpatrick (cc'd)
 tonight about this and he too agrees that 2.0 should not be declared
 final until it has gone through the IPR review cycle to fully ensure
 that it is clear from any IPR encumbrances in regards to the
 contributors.

 You forgot to not cc Brad, and I'd prefer to hear from Brad himself
 then have you channel him.

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




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


Re: OpenID 2.0 finalization progress

2007-10-22 Thread Dick Hardt

On 19-Oct-07, at 10:20 PM, David Recordon wrote:

 Completely agreed with Johannes.  We are very close with the IPR
 policy/process being in place and assuming all the contributors agree
 to it, 2.0 can be declared final within 30 days of October 30th as
 that is the end of the public review period for the policy.  2.0 is
 really important and has a wide range of contributors, we've all put
 a lot of effort into this, lets make sure we do this right.

Doing it right would have been to have had a process in place over a  
year ago. A little late to be doing it right now. Now we are having  
to clean up the mess!


 To Kevin's question, the IPR policy does not require a patent search,
 which as he points out could be a lengthy process.  Rather it
 requires that all contributors to the specification make a non-
 assertion statement to ensure that the spec truly is free and not
 encumbered by any patents.

Just because the contributors all make non-assertion statements does  
not make the spec unencumbered. Non-contributors could have patents  
that are asserted.

While having an IPR policy in place will, provide more certainty  
around the IPR, it will NOT ensure the spec is free.


 I spoke with Brad Fitzpatrick (cc'd)
 tonight about this and he too agrees that 2.0 should not be declared
 final until it has gone through the IPR review cycle to fully ensure
 that it is clear from any IPR encumbrances in regards to the
 contributors.

You forgot to not cc Brad, and I'd prefer to hear from Brad himself  
then have you channel him.

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


Re: OpenID 2.0 finalization progress

2007-10-18 Thread Dick Hardt
I don't see why the two processes need to be any more dependant on  
each other then they are already.

Having  a final spec allows everyone with IP to be clear about any  
IPR statements they are making. In the IPR policy, participants have  
the option to withdraw when a spec is proposed to be final.

I think it is currently embarrassing that we have not made OpenID 2.0  
final. The OAuth project started from nothing to a final spec in the  
last six months. Now they are dealing with IPR.

I'm not saying the IPR policy is not important, just that we don't  
need to deal with these issues serially.

A number of participants are going to sit back until OpenID 2.0 is  
final AND the IPR has been settled. Let's at least knock one of these  
off and build up some more momentum!

-- Dick

On 17-Oct-07, at 7:26 PM, Johannes Ernst wrote:

 My understanding is that we need to get the IPR process finalized,
 then cross all the t's and dot the i's from the intellectual property
 perspective for the 2.0 spec(s), and then declare 2.0 to be final.

 Would be too embarrassing if we declared a spec final and then
 discovered that it did not meet our own IPR requirements re patents,
 for example, wouldn't it?


 On Oct 15, 2007, at 16:00, Dick Hardt wrote:

 +1

 On 15-Oct-07, at 3:02 PM, Josh Hoyt wrote:

 Hello fellow OpenID spec participants,

 As I wrote in August [1], it's time to get the specification  
 declared
 final. We've had quite a while now for implementations and
 specification feedback. Here at JanRain, we've implemented the draft
 specification in Python [2] and PHP [3], and I know that the  
 folks at
 Sxip have implemented and deployed it in Java [4]. I know that at
 least those implementations have beed tested against each other, and
 worked successfully. I haven't heard of any new spec issues raised
 from implementation.

 As such, I am in favor of declaring Draft 12 the final draft and
 blessing it as OpenID 2.0.

 Do the other specification editors agree that now is the time to
 declare OpenID 2.0 finished?

 Josh Hoyt [EMAIL PROTECTED]
 OpenID: http://j3h.us/

 1. http://openid.net/pipermail/specs/2007-August/001953.html
 2. http://openidenabled.com/python-openid/
 3. http://openidenabled.com/php-openid/
 4. http://code.google.com/p/openid4java/
 ___
 specs mailing list
 specs@openid.net
 http://openid.net/mailman/listinfo/specs



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

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



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


Re: OpenID Attribute Exchange Protocol questions

2007-07-10 Thread Dick Hardt

On 10-Jul-07, at 1:47 AM, James Henstridge wrote:

 On 10/07/07, Johnny Bufu [EMAIL PROTECTED] wrote:

 On 6-Jul-07, at 3:54 AM, James Henstridge wrote:

 Would that be appropriate to include in the spec or some best
 practices document?

 I see this as a pure OpenID (core) issue and don't feel the need to
 touch it in the AX spec.

 That would be appropriate if the OpenID authentication spec covered
 the idea of unsolicited OpenID responses.

 Given that it does not cover unsolicited responses and the AX spec
 uses them, it would seem sensible for the AX spec to describe in
 detail how they are meant to work.

The appropriate place would be in the core spec so that other  
extensions would work the same way.

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


Re: OpenID Attribute Exchange Protocol questions

2007-07-10 Thread Dick Hardt

On 10-Jul-07, at 1:47 AM, James Henstridge wrote:


 I don't think it's implied anywhere (or a good design) to keep  
 state
 between the original request and subsequent updates. So the RP  
 cannot
 infer the 'removed' statement just because an update did not  
 contain
 an attribute that was part of the original exchange.

 The update message is a fetch response, so I think it should be
 interpreted as such by the RP: the user has a new phone number.
 Then the RP can decide what it wants to do with the new value,  
 as if
 it had requested the same attributes again.

 Thank you for the clarification.  It seems that an OP will get the
 most consistent results if it always sends all attributes in an  
 update
 then, so it doesn't need to track whether intermediate updates  
 failed
 (or track exactly which attributes were changed).

 Sending all of the originally requested attributes would also require
 the OP to keep an original request data structure for each Fetch
 Request with an update_url in it, with the possibility of
 conflicting / overlapping requests.

 A cleaner way would be to attach a list of update URLs to each
 attribute in the user's profile, and when that attribute's value
 changes to post an update to the RP (after prompting the user etc.).

 The issue I was thinking of was how to handle a lost update.  In
 cases where two attributes are related (like two components of a
 postal address), I'd want to make sure the RP has matching versions of
 those attributes.

 An update could be lost due to temporary network failures, or possibly
 if the RP could not verify the update (e.g. if an association handle
 is used that the RP does not have).

If the OP does not successfully send the update, I would hope that a  
*good* OP implmentation would try again until it was successful.
I imagined that an OP would retain the state of an original request  
and update URL.

Good point brought up about subsequent requests. A mechanism for  
indicating that request B replaces request A is needed so that the RP  
does not get an update for each request that has ever been made.

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


Re: OpenID Attribute Exchange Protocol questions

2007-07-10 Thread Dick Hardt

On 10-Jul-07, at 10:52 AM, Johnny Bufu wrote:


 On 10-Jul-07, at 8:43 AM, James Henstridge wrote:

 On 10/07/07, Dick Hardt [EMAIL PROTECTED] wrote:
  Given that there doesn't seem to be any way to recover from this
  situation, it seems like private associations are the only sane  
 option
  for unsolicited responses.

 An update message would require direct verification and not use an
 association. Associations are set by the RP, and in this case,  
 the OP
 is initiating the conversation. I might be missing something, but I
 don't see how you can reliably use an association.

 That was the conclusion that I came to.

 I was replying to Johnny's statement that the OP knows the expiry  
 time
 of the association handles it stores so could use a previously
 negotiated handle in the unsolicited response.

 I think it would be good to include a statement to this effect in the
 specification so that implementers don't have to work this out for
 themselves (and maybe get it wrong).


 Looks like it's already in the spec, in section 10,  Responding to  
 Authentication Requests:

 If no association handle is specified, the OP SHOULD create a  
 private association for signing the response. The OP MUST store  
 this association and MUST respond to later requests to check the  
 signature of the response via Direct Verification.

 http://openid.net/specs/openid- 
 authentication-2_0-11.html#responding_to_authentication

That does not explain why no association handle was specified. I  
think adding language to explain that an OP may initiate a  
conversation and the message would be verified by Direct Verification  
as no association is available.

-- Dick

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


Re: No New DB Field Requirement? (WAS: RE: Questions about IIW Identifier Recycling Table)

2007-06-08 Thread Dick Hardt
It is more complex having to use two fields to uniquely identify a  
user in a DB then one. DB queries are more complex and there is more  
opportunity for the developer to make mistakes.

Given a goal of OpenID is to be simple, one field is better then two.

-- Dick

On 8-Jun-07, at 10:14 AM, Johnny Bufu wrote:


 On 8-Jun-07, at 10:02 AM, Recordon, David wrote:

 I'm confused as to why a RP having to not create a new DB field is a
 requirement when looking to solve this problem.  RP's implementations
 already need to change to upgrade from 1.1 to 2.0 and this has never
 been a requirement in the past.  It certainly is nice that storage
 changes wouldn't be needed, but I don't see it as something that
 should
 be a requirement.

 My feeling was that, all other things being equal, some bits of code
 (stripping the fragment for display purposes) which ideally would go
 into the library, were preferred to requiring a schema change (to
 store the separate token) for the RPs. Not a requirement, but a
 strong preference.


 Johnny

 ___
 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: Do We Agree on the Problem We're Trying to Solve?

2007-06-08 Thread Dick Hardt
There are ways to solve B that don't really solve A.

In fact, I think the only way to solve B that does not require a  
master directory is orthogonal to solving A.

-- Dick

On 8-Jun-07, at 10:49 AM, Johannes Ernst wrote:

 I would suggest that any solution to B is also very likely a  
 solution to A.

 Anybody disagree?

 If so, I'd suggest that we should either solve A and B at the same  
 time, or not at all.



 On Jun 8, 2007, at 10:42, Dick Hardt wrote:

 At IIW we[1] decided we wanted to solve (A) and that (B) would be
 nice to solve, but we were ok to wait for a future version to
 resolve, as when we discussed (B), resolving looked much harder then
 it seemed at first.

 I'm not certain of where we are now.

 -- Dick

 [1] those present when we met about how to solve recycling ...

 On 8-Jun-07, at 10:35 AM, Recordon, David wrote:

 I'm not sure if we all think we're trying to solve the same problem.
 The two problems that have been discussed are:
 A) Identifier recycling normally in large user-base deployments.   
 i.e.
 insert big company needs a way to give 'TheBestUsernameEver' to a
 new
 user if it has not been used in some period of time.
 B) Losing control of your own domain name whether that be via  
 someone
 stealing it or just that you don't want to have to pay for it  
 forever.

 Have we made a decision as to if we're looking for a solution to  
 solve
 both of these problems, only A, or only B?

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



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



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


Re: Do We Agree on the Problem We're Trying to Solve?

2007-06-08 Thread Dick Hardt
At IIW we[1] decided we wanted to solve (A) and that (B) would be  
nice to solve, but we were ok to wait for a future version to  
resolve, as when we discussed (B), resolving looked much harder then  
it seemed at first.

I'm not certain of where we are now.

-- Dick

[1] those present when we met about how to solve recycling ...

On 8-Jun-07, at 10:35 AM, Recordon, David wrote:

 I'm not sure if we all think we're trying to solve the same problem.
 The two problems that have been discussed are:
 A) Identifier recycling normally in large user-base deployments.  i.e.
 insert big company needs a way to give 'TheBestUsernameEver' to a  
 new
 user if it has not been used in some period of time.
 B) Losing control of your own domain name whether that be via someone
 stealing it or just that you don't want to have to pay for it forever.

 Have we made a decision as to if we're looking for a solution to solve
 both of these problems, only A, or only B?

 --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: Do We Agree on the Problem We're Trying to Solve?

2007-06-08 Thread Dick Hardt
Multiple, redundant identifiers solves B without requiring a master  
directory.

On 8-Jun-07, at 11:06 AM, Johannes Ernst wrote:

 Such as?

 On Jun 8, 2007, at 10:55, Dick Hardt wrote:

 There are ways to solve B that don't really solve A.

 In fact, I think the only way to solve B that does not require a
 master directory is orthogonal to solving A.

 -- Dick

 On 8-Jun-07, at 10:49 AM, Johannes Ernst wrote:

 I would suggest that any solution to B is also very likely a
 solution to A.

 Anybody disagree?

 If so, I'd suggest that we should either solve A and B at the same
 time, or not at all.



 On Jun 8, 2007, at 10:42, Dick Hardt wrote:

 At IIW we[1] decided we wanted to solve (A) and that (B) would be
 nice to solve, but we were ok to wait for a future version to
 resolve, as when we discussed (B), resolving looked much harder  
 then
 it seemed at first.

 I'm not certain of where we are now.

 -- Dick

 [1] those present when we met about how to solve recycling ...

 On 8-Jun-07, at 10:35 AM, Recordon, David wrote:

 I'm not sure if we all think we're trying to solve the same  
 problem.
 The two problems that have been discussed are:
 A) Identifier recycling normally in large user-base deployments.
 i.e.
 insert big company needs a way to give 'TheBestUsernameEver'  
 to a
 new
 user if it has not been used in some period of time.
 B) Losing control of your own domain name whether that be via
 someone
 stealing it or just that you don't want to have to pay for it
 forever.

 Have we made a decision as to if we're looking for a solution to
 solve
 both of these problems, only A, or only B?

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



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



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



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


Re: Do We Agree on the Problem We're Trying to Solve?

2007-06-08 Thread Dick Hardt
On 8-Jun-07, at 2:29 PM, Drummond Reed wrote:

 Multiple, redundant identifiers is what canonical ID mapping  
 provides. It
 doesn't require a master directory; it's as distributed as OpenID  
 itself,
 i.e., it simply provides a way to map a reassignable URL or XRI to a
 persistent URL or XRI.

The persistent URL or XRI *is* a master directory. What do you do  
when the persistent identifier is compromised, goes out of business ...

That is problem B.

Canonical IDs do not solve B.

-- Dick


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


Re: Do We Agree on the Problem We're Trying to Solve?

2007-06-08 Thread Dick Hardt

On 8-Jun-07, at 4:21 PM, Drummond Reed wrote:


 Dick Hardt wrote:

 The persistent URL or XRI *is* a master directory. What do you do
 when the persistent identifier is compromised, goes out of
 business ...

 That is problem B.

 Canonical IDs do not solve B.

 I completely agree that B is a hard problem. However Canonical IDs
 solve B
 if the identifier authority for the Canonical ID follows business  
 and
 operational practices intended to solve B.

 And I think there is a solution that does not require a single,
 central registry.

 Agreed. However XRI as a language for identifier interoperability is a
 superset of the portion of XRI that enables native XRI registries,  
 thus XRI
 Canonical ID architecture can be used with any registry providing
 persistent, verifiable identifiers (XRIs, URLs, Handles, URNs, etc.)

 One of the other issues with the registry is it is challenging to
 provide directed identities.

 Agreed that it is challenging for *global* registries to provide  
 directed
 identities. You'd want to drop down one or more levels of delegation.

Still one point of failure from a specific users point of view.

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


Re: Do We Agree on the Problem We're Trying to Solve?

2007-06-08 Thread Dick Hardt
You are still trusting one registry. Of course it is your choice, but  
you have a single point of failure. Do you think they will still be  
around in 50 years?

On 8-Jun-07, at 4:20 PM, Recordon, David wrote:

 I don't see how it requires a centralized registry, if I choose to  
 trust
 that LiveJournal, or some ugly URL from AOL, etc will never go away  
 then
 that is my choice.

 --David

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
 Behalf Of Dick Hardt
 Sent: Friday, June 08, 2007 4:08 PM
 To: Drummond Reed
 Cc: specs@openid.net
 Subject: Re: Do We Agree on the Problem We're Trying to Solve?


 On 8-Jun-07, at 4:00 PM, Drummond Reed wrote:


 Drummond Reed wrote:

 Multiple, redundant identifiers is what canonical ID mapping
 provides. It
 doesn't require a master directory; it's as distributed as OpenID
 itself,
 i.e., it simply provides a way to map a reassignable URL or XRI  
 to a
 persistent URL or XRI.

 Dick Hardt wrote:

 The persistent URL or XRI *is* a master directory. What do you do
 when the persistent identifier is compromised, goes out of
 business ...

 That is problem B.

 Canonical IDs do not solve B.

 I completely agree that B is a hard problem. However Canonical IDs
 solve B
 if the identifier authority for the Canonical ID follows business and
 operational practices intended to solve B.

 And I think there is a solution that does not require a single,
 central registry.

 One of the other issues with the registry is it is challenging to
 provide directed identities.

 -- Dick

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



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


Re: Attribute Exchange external reference?

2007-06-04 Thread Dick Hardt
The attribute exchanged can be a reference rather then the data  
itself.

http://axschema.org/media/image/default/

Is an example.

-- Dick

On 4-Jun-07, at 12:23 AM, =nat wrote:

 Hi.

 I am kind of new to this field, and this topic may have been discussed
 before, but since a Google search on [site:http://openid.net/ 
 pipermail/
 attribute exchange external reference ] did not match anything, let  
 me bring
 this up.

 On scanning http://openid.net/specs/openid-attribute- 
 exchange-1_0-05.html,
 which looked pretty good, a question Would it be even nicer if we  
 could
 have a hook for external data source? came up to my mind.

 For example, if we could write something like

 openid.ax.type.externalref=http://example.com/schema/ 
 industry_specific_data
 openid.ax.value.externalref=http://example.com/specific_data.xml

 in the response, and have the client fetch the document from http:// 
 example.
 com/specific_data.xml (if it understands the schema type of it), it  
 would be
 useful in bringing OpenID framework and something else together.

 I initially thought that it could be done in the New Attribute Process
 [http://openid.net/specs/openid-attribute- 
 types-1_0-02.html#anchor6], but
 since it requires fetching of external document and thus changes  
 the client
 behavior, I brought up this here.

 Any thought?

 =nat




 ___
 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: Specifying identifier recycling

2007-06-04 Thread Dick Hardt

On 4-Jun-07, at 7:51 AM, Granqvist, Hans wrote:

 So I ask again - does anyone see any issues with the
 fragments being used like this:

  http://openid.net/pipermail/specs/2007-May/001767.html  


 Seems reasonable in essence. But it adds complexity and
 removes some immediacy of URL identifiers-as-is.

 Do fragments need special handling just to handle id
 recycling risks?

 I'm probably missing some context, but can't the issuing OP
 make sure to issue unique IDs, like http://example.com/user1234
 instead of http://example.com/user#1234 ?

Just to clarify the issue:

Users like to have memorable usernames, and likely memorable OpenIDs.

So http://example.com/hans would be a desirable URL at example.com.  
For OPs with literally 100Ms of users, http://example.com/hans would  
be a coveted URL and if it is not being used, example.com would like  
to issue it to someone else.

I think the tradeoff of RPs understanding to strip fragments when  
displaying them is worth removing a barrier for very large OPs from  
joining OpenID.

-- Dick

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


Re: Specifying identifier recycling

2007-06-03 Thread Dick Hardt

On 3-Jun-07, at 2:14 AM, Recordon, David wrote:

 Overall, I'm not sure we are ready in this community to pick one
 alternative over another as the standards. I have my views,
 (many) others have (many) others -- and I don't think that any
 of this has to be in an Authentication 1.x (x1) or 2.0 spec,
 whatever it will be. This seems like a clean add-on.

 I also agree with Johannes here.  I'd like to see this written as an
 extension so that if the first approach doesn't work, the Auth spec
 itself doesn't have to be reverted.  Rather we can finish 2.0 and try
 implementing different approaches before deciding on the final way to
 solve this problem.

I don't see how we can solve this problem as an extension as we need  
the RP to know that a memorable identifier has some extra info that  
makes it unique when reused. This is core to OpenID.

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


Re: Specifying identifier recycling

2007-06-03 Thread Dick Hardt
There is a huge difference between the OP/RP shared secret and using  
a shared secret as an identifier.

The secret between the OP and RP has a mechanism for it to be  
recycled. If it happens to be lost, then the pair can set up a new  
secret.

If the user's secret is lost, then that identifier and any accounts  
that it was used for are lost.

-- Dick

On 31-May-07, at 7:30 AM, Johannes Ernst wrote:

 If we cannot assume that nobody manages to obtain a secret they
 should not have gotten in the first place, then OpenID as it stands
 is rather useless as we cannot trust its  authentication scheme.

 Note that the surface through which the D-H shared secret can escape
 is about twice as large as the surface through which a private key
 can escape -- because an RP does not have access to the private key.
 In other words, if I was an attacker, I'd go after a lot of things
 first before I'd try to obtain a private key.

 Note also that public keys would make rather good i-numbers -- for
 those who would like to, they can ignore that they are public keys
 and do i-number-based verification only, because they are simply
 numbers. For those who don't care about i-numbers, they use their
 public key aspects. Win-win, perhaps?

 There is also the case -- which Stefan Brands would undoubtedly bring
 up if he was on this list -- that the IdP may be hostile, or may
 become hostile. (think of, say, a large OpenID provider going out of
 business, and being bought out by spammer.com -- or just the domain
 name whose registration lapsed) A scheme that is public key based is
 inherently more resilient towards this than one that is not. You
 certainly don't want to trust spammer.com to honor whatever
 conventions the previous owner of the domain put in place to
 disambiguate their users.

 --

 Overall, I'm not sure we are ready in this community to pick one
 alternative over another as the standards. I have my views, (many)
 others have (many) others -- and I don't think that any of this has
 to be in an Authentication 1.x (x1) or 2.0 spec, whatever it will
 be. This seems like a clean add-on.



 On May 30, 2007, at 22:01, Drummond Reed wrote:

 Johannes:

 What about the point Dick posted earlier in this thread, that the
 problem
 with using a public key is if the private key gets compromised?
 Persistent
 identifiers need to persist independent of any attribute changing
 or being
 revoked.

 =Drummond

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
 Behalf
 Of Johannes Ernst
 Sent: Wednesday, May 30, 2007 9:54 PM
 To: OpenID specs list
 Subject: Re: Specifying identifier recycling


 On May 30, 2007, at 21:02, Johnny Bufu wrote:

 ...The bottom line is
 that it can't be done easily - a mechanism similar to XRI's  
 canonical
 ID verification would have to be employed, to confirm that the i-
 number actually 'belongs' to the URL on which discovery was
 initiated. (Otherwise anyone could put any i-number in their URL-
 based XRDS files.)

 Public keys ... public keys ... with the added benefit that no
 centralized or trusted verification service needs to be employed
 whatsoever ...




 Johannes Ernst
 NetMesh Inc.



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

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



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


Re: Proposal for Recycling Identifiers in OpenID 2.0

2007-05-14 Thread Dick Hardt
The issue you bring up is a separate issue then the motivation for  
recycling identifiers by large OPs.

Your point is how does a user transfer from one identifier to another.

The issue at hand is the scarcity of namespace.

-- Dick

On 14-May-07, at 8:48 AM, Johannes Ernst wrote:

 These seems to be an assumption on this thread that
 - identifiers at the same domain name get recycled often (e.g.  
 example.com/jim)
 - domain names don't get recycled often (e.g example.com itself)

 I would suggest that any proposed solution needs to be able to deal  
 with domain names as well that aren't being renewed, and picked up  
 by somebody else. Somebody who isn't necessarily continuing any  
 kind of naming scheme the previous owner had in place, or who is  
 actively hostile with respect to the previous owner.

 There's a whole industry out there recycling domain names -- which  
 proves that this is an issue.




 Johannes Ernst
 NetMesh Inc.


 openid-relying-party-authenticated.gif
 lid.gif
  http://netmesh.info/jernst

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

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


Re: Proposal for Recycling Identifiers in OpenID 2.0

2007-05-14 Thread Dick Hardt

On 14-May-07, at 10:10 AM, Johannes Ernst wrote:


 On May 14, 2007, at 9:12, Dick Hardt wrote:

 The issue you bring up is a separate issue then the motivation for
 recycling identifiers by large OPs.

 What I'm saying is a superset of the issue discussed so far that  
 ought to use the same technical solution because the problem is the  
 same: X used identifier Y, and now Z controls Y. What now?


 Your point is how does a user transfer from one identifier to  
 another.

 While related, that's not the issue I was talking about.

 But you are right in that all of those problems should be solved at  
 the same time.

I'm not saying they should all be solved at the same time.

I think they are different problems and can be solved in different ways.

-- Dick

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


Proposal for Recycling Identifiers in OpenID 2.0

2007-05-13 Thread Dick Hardt
I had the good fortune of discussing URIs, URLs, fragments and the  
recycling issue with a number of smart W3C people at WWW2007 and they  
did not respond with horror at the concept of using fragments to  
recycle identifiers. Given this is a requirement for large OPs, here  
is a proposal. A number of details and issues remain, suggestions and  
constructive criticism encouraged!

-- Dick

Motivating use case:
For large OPs, user identifier namespace is a scarce resource and  
they need to be able to recycle human readable identifiers

Design Considerations:

+ Existing identifiers continue to work
+ A human readable, memorable identifier can be entered by the user  
and displayed to other users
+ A globally unique identifier is user by RPs that is different for  
different users of the same human readable identifier

Proposed Solution:

Allow fragments to be an optional part of the identifier.
An RP could display the URL sans fragment to the users of the website.
RPs would use the complete URL including fragment to identify users.
RPs would be able to delete other accounts with the same base URL  
when seeing a new fragment. (do we want to allow this?)

With OpenID 2.0, the identifier entered by the user does not need to  
be the same as the identifier returned by the OP

To login to an RP, the user could enter openid.op.com/user and if  
the complete identifier managed by the OP was http://openid.op.com/ 
user#7356, this is what would be returned.

The following two identifiers returned by an OP would be considered  
different by an RP: 
http://openid.op.com/user
http://openid.op.com/user#7356

Although the user would enter  openid.op.com/user or   
openid.op.com in the OpenID prompt at the RP.

Outstanding Issues:

When resolving http://openid.op.com/user#7356;, does the RP resolve  
just  http://openid.op.com/user or is does the RP need to find the  
fragment 7536 in the document at  http://openid.op.com/user;? If  
so, where is the fragment? Does it need to occur before. What does it  
mean when the document type is an XRDS document?

Does the document need to contain http://openid.op.com/user#7356;  
for the RP to close the circle on what the OP is stating?

Will this break existing OpenID 1.1 RPs? Which ones? Is this going to  
be an issue for them?


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


Re: encoding newlines in attribute values

2007-04-20 Thread Dick Hardt

On 20-Apr-07, at 11:05 AM, Douglas Otis wrote:


 On Apr 20, 2007, at 10:56 AM, Johnny Bufu wrote:


 On Apr 19, 2007, at 10:46 AM, Josh Hoyt wrote:
 Each attribute already has to define its encoding rules and data-
 type. The mechanism for encoding a newline can be part of this
 encoding, if newlines are allowed in the value. Once there is one
 attribute that has a defined encoding for newline, when new
 attributes are defined, they can re-use this encoding. Does that
 sound reasonable?

 So are you proposing that AX only accepts strings without newline
 characters in them, and the encoding to such a string should be
 handled by the parties who actually consume the attributes, according
 to the type / metadata specs?

 This would be nice and simple for the AX itself, however it would
 require everyone defining attributes to also define a 'encoding to
 strings without newlines' for them.

 The use of base64 can be confined to individual elements within an
 attribute where newlines are _not_ affected.  There should be a
 standardized template for declaring base64 encoding starts with 'X'
 and ends with 'Y';

Great idea Douglas.

To expand on that and include Mark Wahl's proposal about locale  
encoding[1] in a standard way for attributes so that the libraries  
can do the right thing 99% of the time.

I would propose that AX data have a default encoding that can be  
overrode by the attribute metadata. The default would be:

URL encoding for text data
escape sequence for locale using mechanism in RFC 3866
escape sequence to indicate binary data that is then base64 encoded

[1] I see that Mark's proposal is not up on the site yet. It is a  
good proposal though!
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs


axschema.org instead of openid.net

2007-04-20 Thread Dick Hardt
Thanks everyone for feedback on using schema.openid.net. Here are my  
conclusions:

1) A number of people would like to be using a web oriented schema  
right away and don't want to wait for other groups to create the schema.

2) A number of people are allergic to the openid.net domain being  
used for things that are not openid.net protocol specific.

Sxip has acquired axschema.org (Attribute eXchange schema :-) and we  
will host the site and a mail list as a service to the community and  
operate it per http://openid.net/specs/openid-attribute- 
types-1_0-02.html

If I don't hear from anyone that they don't like this idea, then we  
will set this up next week.

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


Re: [dev-monkey] Newlines in bio attribute

2007-04-11 Thread Dick Hardt
use a common escape sequence ... may need to define one for AX  
anyways ...

On 10-Apr-07, at 2:07 PM, Rowan Kerr wrote:

 The OP doesn't like newlines in attribute values. Which isn't that  
 surprising because handling of newlines isn't even described in the  
 OpenID AX spec yet.

 But, if we want to allow people to submit a bio to the profile  
 site, we'll have to deal with them.

 One possible solution:
 Have Sxipper client and the Profile site define a common way of  
 escaping newlines in attribute values.
 - Sxipper would replace newlines with a token before sending  
 message to OP.
 - Profile site would replace tokens with newlines before saving to  
 database.

 Thoughts?

 -Rowan



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


Re: in favor of allowing a fragment in a URI for metadata for an attribute type

2007-04-11 Thread Dick Hardt
btw: my main driver in stating +1 is that I was concerned with how it  
would be implemented, and given that Mark has the one working parser  
and is ok with it, then my concern has disappeared!

On 10-Apr-07, at 5:52 PM, Dick Hardt wrote:

 Good argument Mark, I concur. +1

 -- Dick

 On 10-Apr-07, at 4:52 PM, Mark Wahl wrote:


 Section 4.3 of
 http://openid.net/specs/openid-attribute-types-1_0-02.html
 suggests that in URIs defined for attributes for OpenID AX,
 URI fragment specifiers should not be used.

 Now I'm no RDF expert, but I'm in favor of allowing fragments,
 and perhaps even encouraging them. I'd prefer this statement
 be removed from subsequent versions of the OpenID AX, in order
 to not dissuade other schema developers from using fragments.
 Here are some points for discussion on that topic, I'd be
 interested in hearing feedback esp. from other RDF implementors.

 0. Some servers will have but a single, small, fixed schema.  I'd
 rather those servers be able to reference and serve a single RDF
 file with their complete schema, instead of needing to break that
 schema into a bunch of little schemas.

 For example, suppose a server only supports FOAF.  Now FOAF does not
 use fragments for the property definitions for its attribute types,
 but the attribute types defined in FOAF are not currently resolvable
 to an RDF document that describes those attribute types.

 If xmlns.com where the FOAF RDF is hosted were to implement having
 these
 attribute type URIs used in FOAF be resolvable, they
 would either need to
   - create a few dozen little RDF files that together mirror the
 content of
 foaf.rdf, or
   - implement a URI rule that http://xmlns.com/foaf/0.1/*
 returns foaf.rdf

 If I were redefining FOAF, I'd have its attributes be defined as
 fragments,
 so that there is only one base URI for the FOAF schema.  (Also to  
 give
 them RDF class definitions, see below).

 1. It appears to be current practice for RDF representations of
 metadata
 for attributes in Higgins to use fragments.

 In OWL-based systems, the RDF object at the base URI of the document
 is an OWL Ontology.

 In Higgins, which uses OWL, the object at the base URI is an OWL
 Ontology that 'imports' the Higgins Ontology.  The RDF file for
 an attribute contains an OWL Class for the attribute named by a
 fragment,e.g., #Firstname, and several related OWL properties and
 RDF instances in that same file that add structure to that class.

 2. In our 'schemat' implementations which attempt to generate RDF for
 existing schemas of 'legacy'/'installed base' protocols, it is
 desirable to
 be able to have additional, named OWL classes, RDF objects, and other
 modelling and descriptive data definitions that are shared across
 multiple attributes of a single schema. For example, a schema may
 define its own value syntax and matching rules, and wish to share
 those syntaxes and matching rules across the attributes of that
 schema.
 It would be desirable if there could be a single RDF file which
 contains
 the attribute type metadata, the syntax definition and matching rule
 definition, rather than needing to have the attribute type metadata
 in a set of files that are separate from the syntax definitions and
 matching rule definitions, or are duplicated in those files.

 3. I find that in our implementation 'schemat' of identity metaschema
 attribute metadata retrieval that is a definite performance gain if
 all the schema elements for a particular schema can be retrieved in
 a single HTTP GET.  It is likely that an implementation interested
 in an attribute Firstname of a particular schema would also be
 seeing a few other attributes Lastname, Middlename etc of the same
 schema, and it would be good if a GET that retrieves the data for
 Firstname also gives the implementation the rest of the schema so
 that it does not need to keep going back and GETing for each
 attribute type.

 4. Requiring that each be in a separate document would likely lead to
 duplication of metadata, particularly Dublin Core metadata that
 describes the schema as a whole.  I feel it would be better if the
 RDF object at the base URI has the Dublin Core metadata for the
 schema as a whole, and that the Attribute Type Metadata is a class
 named by a fragment below that base URI.

 5. (appeal to authority) http://www.w3.org/DesignIssues/Fragment.html
 This means that identifiers for arbitrary RDF concepts should have
 fragment identifiers. 


 Mark Wahl
 Informed Control Inc.

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



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



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


Re: PROPOSAL schema.openid.net for AX (and other extensions)

2007-04-10 Thread Dick Hardt

On 9-Apr-07, at 5:24 PM, Recordon, David wrote:

 Yes, I agree an upgrade path from SREG is needed.  We could however do
 something as simple as
 http://openid.net/specs/openid-simple-registration- 
 extension-1_0.html#ni
 ckname for the existing SREG fields.

by making this a fragment, you force a requirement that Mark's tool  
has to be able to dig into a document and find the anchor as opposed  
to the attribute being self contained -- a complication I am not sure  
we want to deal with at this point in the meta-data

why not have a page that maps the existing SREG to the AX attributes  
we have already defined? why create yet-another set of attributes?

Myself, I think a developer would like to look in ONE place to find  
all the common web related attributes she will likely need so that  
she can build her app and not have to go looking across a dozen  
different sources to write some code.

There will definitely be attributes that are for specific  
communities, so the developer will need to look in a few places, but  
why make it harder then it needs to be at this point in time?

A number of people have spoken up to vote +1 to use  
schema.openid.net. Given that you have the magic wand David, are you  
going to let the community progress or do we have to keep arguing  
with you until one party wears out and gives up?

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


Re: Web Access Management

2007-04-09 Thread Dick Hardt
Deal with the IPR issue ...

On 9-Apr-07, at 12:54 PM, McGovern, James F ((HTSC, IT)) wrote:

 So, what will it take to move the mentioned vendors from simply  
 being aware to actively participating?

 -Original Message-
 From: Dick Hardt [mailto:[EMAIL PROTECTED]
 Sent: Sunday, April 08, 2007 2:48 PM
 To: McGovern, James F (HTSC, IT)
 Cc: specs@openid.net
 Subject: Re: Web Access Management


 Tony Nadalin from IBM and Dale Olds from Novell are well aware of
 what is happening in OpenID.

 The lack of a clear IPR policy is preventing Microsoft from directly
 participating in the mailing lists. A number of us met at Microsoft
 [1] and this was one of the issues that we are working to address.

 btw: I think this is a better topic for [EMAIL PROTECTED] rather
 then specs ...

 [1] for the conspiracy minded, nothing happening behind closed doors,
 the meeting was publicly announced and anyone was welcome to attend.
 A number of us are kicking ourselves for not taking good notes that
 we could post to the list.

 -- Dick


 ** 
 ***
 This communication, including attachments, is
 for the exclusive use of addressee and may contain proprietary,
 confidential and/or privileged information.  If you are not the  
 intended
 recipient, any use, copying, disclosure, dissemination or  
 distribution is
 strictly prohibited.  If you are not the intended recipient, please  
 notify
 the sender immediately by return e-mail, delete this communication and
 destroy all copies.
 ** 
 ***

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



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


Re: PROPOSAL schema.openid.net for AX (and other extensions)

2007-04-09 Thread Dick Hardt
The list is a set of xml files that we wanted to post on  
schema.openid.net so that everyone could see them per the proposed  
draft.


Each attribute has a chunk of meta data around it.

( the files are all viewable and browsable as well as being machine  
readable)


A good OP would dynamically add new attributes as they become  
available as opposed to statically coding a set.


If you would be kind enough to let us set up schema.openid.net, then  
we could more easily show everyone.


-- Dick

On 9-Apr-07, at 8:23 PM, Recordon, David wrote:

Is there a list anywhere?  I didn't find one in the documents and I  
think this list would benefit everyone in the conversation.  I'm  
just curious as to the fields you're expecting an OP to implement.


--David


 -Original Message-
From:   Dick Hardt [mailto:[EMAIL PROTECTED]
Sent:   Monday, April 09, 2007 07:12 PM Pacific Standard Time
To: Recordon, David
Cc: James Walker; Martin Atkins; Mark Wahl; OpenID specs list
Subject:Re: PROPOSAL schema.openid.net for AX (and other  
extensions)



On 9-Apr-07, at 5:24 PM, Recordon, David wrote:

 For new fields, is there a reason we can't use the ldap.com URLs  
Mark

 posted as a starting point?  I know Dick said they didn't cover all
 the
 needed attributes, but would it be good enough to start with and  
then
 expand from there possibly on schema.openid.net?  Dick, do you  
have a

 list of attributes you see as needed for the first implementations
 of AX
 (I couldn't find one in the current AX specs though I fully admit I
 may
 be looking in the wrong place)?

There are many, many attributes that we are using in AX that are not
in LDAP, or don't have the granularity.

-- Dick





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


Re: Web Access Management

2007-04-08 Thread Dick Hardt
Tony Nadalin from IBM and Dale Olds from Novell are well aware of  
what is happening in OpenID.

The lack of a clear IPR policy is preventing Microsoft from directly  
participating in the mailing lists. A number of us met at Microsoft 
[1] and this was one of the issues that we are working to address.

btw: I think this is a better topic for [EMAIL PROTECTED] rather  
then specs ...

[1] for the conspiracy minded, nothing happening behind closed doors,  
the meeting was publicly announced and anyone was welcome to attend.  
A number of us are kicking ourselves for not taking good notes that  
we could post to the list.

-- Dick

On 5-Apr-07, at 12:00 PM, McGovern, James F ((HTSC, IT)) wrote:

 The RSA CTO is Bret Hartman, the Netegrity CTO is Vadim Lander. I  
 would also suggest inviting Marc Wilcox from Oracle. I don't know  
 the names of folks from Novell or IBM. Would be great if Dick  
 reached out to them.

 -Original Message-
 From: Hans Granqvist [mailto:[EMAIL PROTECTED]
 Sent: Thursday, April 05, 2007 1:05 PM
 To: Dick Hardt
 Cc: McGovern, James F (HTSC, IT); specs@openid.net
 Subject: Re: Web Access Management


 Ping demoed OpenID technology at RSA.

 I hear Novell and IBM are looking at supporting OpenID.

 Microsoft has said they will in future products.

 Oracle and CA are following OpenID.

 So, yes. :-)


 I'm curious why almost all of these companies are non-existent
 on the mailing lists.  Any insights?

 -Hans



 ** 
 ***
 This communication, including attachments, is
 for the exclusive use of addressee and may contain proprietary,
 confidential and/or privileged information.  If you are not the  
 intended
 recipient, any use, copying, disclosure, dissemination or  
 distribution is
 strictly prohibited.  If you are not the intended recipient, please  
 notify
 the sender immediately by return e-mail, delete this communication and
 destroy all copies.
 ** 
 ***

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



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


Re: Promoting OpenID

2007-04-08 Thread Dick Hardt

On 5-Apr-07, at 8:46 PM, Johannes Ernst wrote:

 On Apr 5, 2007, at 18:36, Chris Messina wrote:

 ... I personally think selling to the enterprise is nearly
 impossible without tons of grassroots adoption ...

 I disagree. ;-)

 Now granted, there are many, many things that we all need to do and  
 that need to happen to make OpenID suitable for the enterprise  
 market on a mass market basis. People like James keep reminding  
 us of that on this list and in other places, and please keep it  
 coming.

 But it's definitely not the case any more that it is impossible...

I think you are missing a key part of Chris statement ... without  
tons of grassroots adoption ...

If the grassroots don't support OpeniD, very unlikely that the  
enterprise will.

-- Dick

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


Re: PROPOSAL schema.openid.net for AX (and other extensions)

2007-04-08 Thread Dick Hardt
Hi Mark

The URL mapping of LDAP attributes below looks pretty useful. Some of  
those overlap with attributes we defined for AX, but many of the  
attributes in AX are not defined, or don't have the same granularity.

Given that LDAP attributes were defined per the needs of enterprise,  
and AX attributes reflect the attributes commonly requested on public  
web forms, this is to be expected.

With a goal of making it easy for people to use AX, I'd like to have  
a list of common web oriented attributes readily available for  
developers to work with.

What do you think of using the equivalence mechanisms to map common  
attributes between the two sets, but allowing the two sets  to  
maintain their focus on solving the problems for their separate  
communities? ... or do you think we should try and come up with a  
master set of core attributes?

-- Dick

On 8-Apr-07, at 1:01 PM, Mark Wahl wrote:

 Dick Hardt wrote:

 If there was something out there already, I would propose we used  
 it.  There is not.
 Just like the SAML crowd has accused the OpenID crowd of  
 reinventing  an identity protocol (AKA reinventing the wheel) --  
 the AX proposal  has some unique concepts that people like Paul  
 and Mark think are  quite innovative. Other schemas don't support  
 them.
 I have cc'ed Paul and Mark in case they can point to some new  
 work  that we can take advantage of today.

 FYI if you are carrying attribuets in OpenID AX that are equivalent to
 LDAP attributes with attribute types being standardized in the  
 IETF, then
 you could use our LDAP schema definition metadata.   We have  
 resolvable
 HTTP URIs for each of the widely-deployed attributes, such as  
 givenName.

 Background:

 In order to get some test data for developing our Schemat 'reference
 implementation' of identity metasystem schema management tools, we
 (Informed Control) have been generating metadata for the LDAP/X.500  
 schema
 definitions that are in IETF RFCs.

 For our first cut, we took the definitions from these RFCs:

 2079 Definition of an X.500 Attribute Type and an Object Class to Hold
  Uniform Resource Identifiers (URIs). M. Smith. January 1997.  
 (Format:
  TXT=8757 bytes) (Status: PROPOSED STANDARD)

 2798 Definition of the inetOrgPerson LDAP Object Class. M. Smith.
  April 2000. (Format: TXT=32929 bytes) (Updated by RFC3698,  
 RFC4519,
  RFC4524) (Status: INFORMATIONAL)

 4512 Lightweight Directory Access Protocol (LDAP): Directory
  Information Models. K. Zeilenga, Ed.. June 2006. (Format:  
 TXT=108377
  bytes) (Obsoletes RFC2251, RFC2252, RFC2256, RFC3674) (Status:
  PROPOSED STANDARD)

 4519 Lightweight Directory Access Protocol (LDAP): Schema for User
  Applications. A. Sciberras, Ed.. June 2006. (Format: TXT=64996  
 bytes)
  (Obsoletes RFC2256) (Updates RFC2247, RFC2798, RFC2377) (Status:
  PROPOSED STANDARD)

 4524 COSINE LDAP/X.500 Schema. K. Zeilenga, Ed.. June 2006. (Format:
  TXT=11245 bytes) (Obsoletes RFC1274) (Updates RFC2247, RFC2798)
  (Status: PROPOSED STANDARD)

 and generated RDF/XML files with metadata translated into OWL from the
 LDAP representation.

 (We picked those RFCs since there was already a change control and
 standardization process for them, they represented rough concensus
 as a minimum interoperable set of definitions, the objectclasses in
 them are stable, these schemas are widely supported by many LDAP  
 servers
 as a native schema, and contained the schema used in example LDIF/DSML
 files.  There are certainly other non-obsolete RFCs containing LDAP
 schemas, which we'll address later as there's interest; I don't think
 there's any technical limitations that would have prevented us from
 extracting metadata from them).

 For each LDAP attribute type definition in those RFCs, the schemat
 tool generated an OWL DatatypeProperty and a OWL Class.

 The URI of the OWL class generated from an LDAP attribute type
 is currently of the form

 http://www.ldap.com/1/schema/rfc.owl#AttributeType_OID

 where  is the number of the RFC, and OID is the string encoding
 of the attribute's object identifier.  (We chose to use the OID in the
 URI, rather than a string, since LDAP allows an attribute to have
 multiple string names, and does not have a 'primary' string name.
 Having to equivalentClass between multiple Classes for a single
 LDAP attribute type definition seemed worse than having one Class
 with an identifier already known to be unique).  We chose the ldap.com
 domain name as we have it :-) and these are LDAP-developed  
 definitions;
 I'm not wedded to the ldap.com domain name, and considered two  
 alternatives:
  - using an 'oid' URI form
   This would be a suitable alternative URI, however, this
   would introduce a dependency on a oid URN namespace
   resolver, which isn't yet operational.
   
  - using an ietf.org or iana.org domain name
   This would be our preferred long-term strategy

Re: some questions on OpenID AX 1.0 draft 4

2007-04-08 Thread Dick Hardt
Hi Mark, for some reason I just saw this post, answers and questions  
inserted ...

On 5-Apr-07, at 9:47 AM, Mark Wahl wrote:


 http://openid.net/specs/openid-attribute-exchange-1_0-04.html

 1. Section 2 states that the store operation saves or updates
 attribute information on the OpenID Provider.

 How does an RP delete an attribute when updating information on the
 OP?

The OP is not a repository for the RP. It is a repository for the  
user. RPs store data at the OP that the user might find useful  
somewhere else.


 2. Section 3.2 states that If an attribute type identifier URI
 can be resolved then it MAY be dereferenced to retrieve a
 description of the property.

 In this protocol, who is doing the dereferencing?  Would an OP
 return an error during a store if it resolved the URI and there was
 no description of the property there?

This feature was created to allow an OP to dereference an attribute  
requested by an RP that the OP did not understand and dynamically  
assist the user in providing the attribute.

The meta-data could provide labels and syntax so that the OP could  
prompt the user for the value, or the meta-data could indicate to the  
OP where the user could go do get the attribute.



 3. Section 3.3 states that an attribute value MUST be a UTF-8 string.

 Are any UTF-8 characters permitted?  How is a newline escaped, as
 Section 4.1.1 of http://openid.net/specs/openid- 
 authentication-2_0-10.txt
 states that A key or value MUST NOT contain a newline.

escaping of chars if needed is dependent on the syntax of the data in  
the attribute. The idea this was out of scope of AX and dependant on  
specific attributes.


 Presumably RFC 2482 characters (plane 14 language tags) are OK?  Or  
 are
 language tags of values carried through some other means?

UTF-8 would preclude language tags would it not?


 How can the RP determine the maximum value length that an OP will
 support for a particular attribute?

no upper limit defined ... suggestions?



 4. Section 5.1 states that Attribute aliases MUST NOT contain
 newline and colon characters,... they also MUST NOT contain commas.

 What is the significance of a period character?  Can an alias
 contain a period?

no -- looks like that should be added to the spec


 What is the maximum length of an alias string that an RP can expect
 an OP to support?

suggestions?



 5. Section 5.1 states that if openid.ax.if_available parameter is  
 present
 The OpenID Provider MAY provide the identity information specified  
 in this
 parameter..  How does the RP determine the schema of the provider  
 to know
 what to ask for?

Don't understand this question.


 6. Section 5.1 states that openid.ax.count.alias is the number of
 values for the specified attribute alias the Relying Party wishes to
 receive from the OpenID Provider. If present, the value MUST be  
 greater
 than zero. If absent, exactly one value is requested. OpenID Providers
 MUST NOT return more than the number of requested values.

 What is the largest value of count that an RP that wants all values
 can submit that an OP will support?  2^31? 2^32? 2^63?

See thread with Josh. Suggested value?


 7. Section 5.2 states that The value of the openid.ax.type.alias
 parameter specifies the type identifier URI for the attribute referred
 to as alias. MUST be present if, and only if, this exact parameter
 was included in the fetch request.

 It's not clear to me how subtyping of attributes is handled.

 Suppose the OP holds a 'person' with attributes

 ldap:///cn=schema#cn:  John Smith
 ldap:///cn=schema#cn:  Johnny Smith
 ldap:///cn=schema#surname: Smith
 ldap:///cn=schema#givenName: John
 ldap:///cn=schema#patronymic: Paul

 Now the attribute types ldap:///cn=schema#cn,
 ldap:///#cn=schema#patronymic, ldap:///cn=schema#surname,
 ldap:///cn=schema#givenName are all subtypes of a generic  
 attribute
 type ldap:///cn=schema#name.  In LDAP directories, when one  
 asks for
 a 'name' attribute, that's a shorthand for asking for any of the  
 naming
 attributes, which can be useful if the requestor doesn't know in  
 advance
 what schema attributes the server uses for naming people.

 A RP issues a fetch request for ldap:///cn=schema#name, asking for
 any naming information .  The OP doesn't have a #name attribute  
 in that
 person, but does have #cn, #surname, #patryonmic and #givenName  
 attributes.
 How should the OP encode these types in the fetch response to the RP?

AX has a simple model that you ask for an attribute and you get it.

If the meta-data states that different types are equivalent, then you  
can get one of those.



 8. Section 6.1 states that openid.ax.value.alias assigns a value  
 to the
 attribute referred to as alias.

 Is an OP receiving a store response required to save the alias  
 provided by the
 RP for any purpose, or is the alias merely used in a particular  
 protocol
 interaction?

alias is just for the 

Re: Moving AX Forward (WAS RE: SREG namespace URI rollback)

2007-04-06 Thread Dick Hardt

On 5-Apr-07, at 9:18 AM, Recordon, David wrote:

 I don't think this is really that important of a point given all the
 other things we need to do. People are doing to do things different
 then you would, but get the same result -- is that ok?
 I'm fine with doing things differently, I'm not arguing that a  
 metadata
 format should not be created, just that IMHO for simplicity sake of
 reading the AX documents this format description should be merged into
 the core protocol spec.  If down the road it should be split out  
 then it
 always can be.

Well, as one of the people that wrote the documents. We decided that  
having separate documents was better. Thanks for sharing your  
opinion. I have a different opinion.


 We wanted to publish them on the website so that other people could
 look at them, but you did not want to do that, and you control the
 domain.
 Dick, that isn't a fair statement at all.  It is not my decision to  
 make
 if schemas.openid.net should be created and the content you're  
 proposing
 put there.  I've asked you multiple times to have a conversation on  
 this
 list ending in a formal vote (like we've done for many other spec
 decisions) to make this decision.  If I've missed this vote then  
 please
 point me at it.

I don't recall you ever actually telling me to have a vote. You  
stated you did not want to do it and to find some other home.

I wanted to setup the schemas so that people could see how it worked,  
then I could actually get constructive comments back from the list  
and have something tangible to vote on.

I have no ideal what the formal vote process on OpenID. The only  
that I know of that is documented is the process for approving the  
OpenID Authentication 2.0 specs.

I'll post a question to the list if that is what you want.

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


Re: Moving AX Forward (WAS RE: SREG namespace URI rollback)

2007-04-06 Thread Dick Hardt

On 5-Apr-07, at 9:24 AM, Recordon, David wrote:

 Dick, see my other message but this is not about ME stopping you!
 We wanted to publish them on the website so that other people could
 look at them, but you did not want to do that, and you control the
 domain.

 Dick, that isn't a fair statement at all.  It is not my decision to
 make if schemas.openid.net should be created and the content you're
 proposing put there.  I've asked you multiple times to have a
 conversation on this list ending in a formal vote (like we've done
 for many other spec decisions) to make this decision.  If I've missed
 this vote then please point me at it.

 I'm quite honestly not sure what more to say.  If you want to see this
 work happen then you need to take the initiative and make it happen.
 You can't just expect to post a few messages to the ID Schemas list  
 and
 have them magically start working.

 I'm all about taking advantage of existing momentum, but I have a hard
 time seeing anyone who cares about AX being unwilling to have this
 discussion as a part of the ID Schemas community.  If there is anyone,
 I'd certainly like to understand the reasons why (beyond it being
 hard).

We wrote a spec.

We have working code.

Other people have developed code as well.

We need to publish a schema so that we can systems talk to each other.

If *you* would like to see the work done over in ID Schemas, then  
*you* can work to make it happen there. The same for other people. If  
the work shifts to there, I am fine with it. Right now, I'm fine with  
doing the work here on the OpenID specs list.

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


PROPOSAL schema.openid.net for AX (and other extensions)

2007-04-06 Thread Dick Hardt
OpenID Attribute Exchange (AX) uses URLs to uniquely identity  
attributes. The URLs are resolvable to provide meta data that is both  
machine and human readable.

In order to do anything useful with AX, some commons identity  
attributes need to be defined.

I would propose that we start off using URLs based off of  
schema.openid.net.

The Metadata model has provisions for stating that a given URL is  
equivalent to another one, so that if and when a more authoritative   
source is available, the schema.openid.net URLs can reference a  
source that would be considered more appropriate. ie. we are not  
locked forever to the schema.openid.net domain.

Is there a better domain that could be used? Likely, but as a  
community we have control over openid.net and we can make this happen  
now so that we can move forward with development.

Issues?

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


Re: PROPOSAL schema.openid.net for AX (and other extensions)

2007-04-06 Thread Dick Hardt
If there was something out there already, I would propose we used it.  
There is not.

Just like the SAML crowd has accused the OpenID crowd of reinventing  
an identity protocol (AKA reinventing the wheel) -- the AX proposal  
has some unique concepts that people like Paul and Mark think are  
quite innovative. Other schemas don't support them.

I have cc'ed Paul and Mark in case they can point to some new work  
that we can take advantage of today.

Other responses inserted:

On 6-Apr-07, at 11:49 AM, Recordon, David wrote:

 As I've stated in the past, I have no problem with using
 schema.openid.net to define attributes such as the authoritative  
 URI for
 an OpenID URL, i-name, etc.

 I do have a problem with using this namespace to define an attribute
 such as a First Name.  I do not feel that this community should be
 dealing with all of the issues such as First Name vs. Given Name, as
 that is not where the expertise is, let alone it has been done in the
 past.  I also strongly believe that due to the number of other
 definitions of these attributes, either we as a community should  
 decide
 to use one of them or work with a project such as ID Schemas to  
 create a
 set of URIs not tied to the OpenID project that solves both our needs
 and the needs of others.  I do not particularly care where this work
 would happen and as I've said in the past, I'd be fine with someone  
 just
 buying a domain to do the work to preserve the speed for getting this
 bootstrapped while not tying it to OpenID.

If really don't care, then you should not care if it is happening in  
OpenID then.


 First Name:
  - http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname

This URL could be used. To date they have not made these self  
describing. Who knows what this is? The AX proposal is to make the  
URLs describing. This makes it easier for programmers to know what it  
is they are working with.

  - http://xmlns.com/foaf/0.1/firstName
  - http://xmlns.com/foaf/0.1/givenname

Both of these are elements in a larger XML document. This is not the  
model of AX.

  - http://en.wikipedia.org/wiki/First_name

While intriguing to have wikiality define terms, this is not  
practical since the definition needs to be static or code will break


 I'm sure if Paul Trevithick or Mark Whal join this conversation they'd
 be able to highlight even more URI definitions of a First Name than I
 was in a cursory search.  This also isn't including all of the work  
 done
 for things such as LDAP, vCard, or others listed at
 http://idschemas.idcommons.net/moin.cgi/List_Of_Schemas in defining  
 what
 these schema attributes are and mean.

Most other work has created closed schemas. The AX proposal is an  
open schema where anyone can define a new attribute and each one is  
self describing.


 If we want to create URLs for attributes from an existing schema (such
 as LDAP or vCard) since easy URLs do not currently exist, then that is
 one thing.  Creating an entirely new definition of commonly used
 attributes IMHO is unacceptable.

People keep doing it for a variety of reasons. People keep inventing  
new programming languages.


   We should be reusing anything that we
 can, not inventing something new especially given the complexity of  
 this
 particular task.

The task has largely been done. Still need to finalize the meta-data  
file format.


 I'm not sure what more I can do to urge this community to not reinvent
 the wheel in this area.

See comment at top. AX does not need a wheel. AX needs a wing. Wings  
don't exist right now.

-- Dick




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


Re: PROPOSAL schema.openid.net for AX (and other extensions)

2007-04-06 Thread Dick Hardt
The work is not rooted in openid.net. We are starting there. We can  
easily point those definitions somewhere else later, but we need  
somewhere to start.

Given that the community that cares today is in OpenID, and the  
domain the community has is openid.net, it would make sense to use  
that domain. A different domain is going to have the same issues of  
control. I would expect that other members of the community would  
have concerns if it was rooted at say sxip.org.

Happy to have further discussions at IIW, but don't see why the work  
here should wait until then. Other communities may or may not want to  
take advantage of what we are doing, and it will be easier for them  
to understand what we have if we have working code then just more  
talk about it.

To take a step back, the people to decide this should be the people  
that are doing implementations. Would you clarify David if *you* are  
implementing, or just sharing your opinion?

If anyone implementing would like to do something different, then I'd  
welcome additional discussion, otherwise I think we should be able to  
move forward with the proposal.

-- Dick

On 6-Apr-07, at 2:03 PM, Recordon, David wrote:

 I think it is great that there is new and innovative work in what  
 you've
 been doing.  I would also think that it would benefit the entire
 user-centric (and even non-user-centric) community to take  
 advantage of
 this work regardless of the technology.  By having it rooted on
 openid.net, I think there will be aversion to doing so and other
 communities will rather jump to the conclusion that the OpenID  
 community
 is yet again reinventing the wheel by defining common core attributes.
 This is what I want to avoid.

 By doing this in a neutral location, not tied to a specific identity
 technology, it removes this concern as well as does more good for the
 entire ecosystem.  If the ID Schemas project is not the right place to
 do it, then I see no reason not to create one; I would be happy to  
 front
 the cost of a domain name if needed.

 I'd also think this would be something worth discussing at IIW when  
 the
 entire community comes together.  I would really like to see this be
 something that can be used by OpenID, CardSpace, Higgins, SAML, etc.

 --David

 -Original Message-
 From: Dick Hardt [mailto:[EMAIL PROTECTED]
 Sent: Friday, April 06, 2007 1:07 PM
 To: Recordon, David
 Cc: OpenID specs list; Paul Trevithick; Mark Wahl
 Subject: Re: PROPOSAL schema.openid.net for AX (and other extensions)

 If there was something out there already, I would propose we used it.
 There is not.

 Just like the SAML crowd has accused the OpenID crowd of  
 reinventing an
 identity protocol (AKA reinventing the wheel) -- the AX proposal has
 some unique concepts that people like Paul and Mark think are quite
 innovative. Other schemas don't support them.

 I have cc'ed Paul and Mark in case they can point to some new work  
 that
 we can take advantage of today.

 Other responses inserted:

 On 6-Apr-07, at 11:49 AM, Recordon, David wrote:

 As I've stated in the past, I have no problem with using
 schema.openid.net to define attributes such as the authoritative URI
 for an OpenID URL, i-name, etc.

 I do have a problem with using this namespace to define an attribute
 such as a First Name.  I do not feel that this community should be
 dealing with all of the issues such as First Name vs. Given Name, as
 that is not where the expertise is, let alone it has been done in the
 past.  I also strongly believe that due to the number of other
 definitions of these attributes, either we as a community should
 decide to use one of them or work with a project such as ID  
 Schemas to

 create a set of URIs not tied to the OpenID project that solves both
 our needs and the needs of others.  I do not particularly care where
 this work would happen and as I've said in the past, I'd be fine with
 someone just buying a domain to do the work to preserve the speed for
 getting this bootstrapped while not tying it to OpenID.

 If really don't care, then you should not care if it is happening in
 OpenID then.


 First Name:
  - http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname

 This URL could be used. To date they have not made these self
 describing. Who knows what this is? The AX proposal is to make the
 URLs describing. This makes it easier for programmers to know what it
 is they are working with.

  - http://xmlns.com/foaf/0.1/firstName
  - http://xmlns.com/foaf/0.1/givenname

 Both of these are elements in a larger XML document. This is not the
 model of AX.

  - http://en.wikipedia.org/wiki/First_name

 While intriguing to have wikiality define terms, this is not
 practical since the definition needs to be static or code will break


 I'm sure if Paul Trevithick or Mark Whal join this conversation  
 they'd
 be able to highlight even more URI definitions of a First Name than I
 was in a cursory search.  This also isn't

Re: Re[2]: Server-to-server channel

2007-04-05 Thread Dick Hardt

On 4-Apr-07, at 8:59 PM, Chris Drake wrote:

 Thursday, April 5, 2007, 5:43:02 AM, you wrote:

 [snip]

 DO How these keys are handled internally could be left to the
 DO consumer or RP.

 [snip]

 This sounds like another *strong* use-case for updating the OpenID
 protocol to allow transactions to take place when the user is not
 present.

 I am not likely to be present when people relying upon my certificates
 choose to verify signatures, check for revocation, or attempt to
 encrypt stuff destined for me.

 There needs to be a way for the RP to contact my OP and get access to
 my information (eg: my current public key and revocation list) - by my
 explicit prior consent of course.

Having your public key discoverable at your URL makes lots of sense,  
it is by its very nature, public.

I would not consider fetching the public key to be a transaction though.

-- Dick

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


Re: Moving AX Forward (WAS RE: SREG namespace URI rollback)

2007-04-05 Thread Dick Hardt
Doing the work in the ID Schemas project  was a good idea 3 months  
ago and 6 months ago. So far not much has happened there.

I agree that having several groups do the same thing is undesirable,  
but we do need to get moving.
We need URIs for moving attributes today. We can wait for the metadata 
[1] to get defined, and the members of the ID Schema group are the  
right people for that.[2]

While it is desirable that there is only one definition of an  
attribute, and some people may define the same attribute through lack  
of knowledge of each other. The attribute meta data model proposed[1]  
allows for one definition to reference another definition to  
consolidate attribute definitions.

Additionally, getting everyone to agree on the syntax will be hard.  
The model allows different people to define attributes in different  
ways. The market will decide then what works best through use.

btw: Currently there is no consistent, extensible, self describing  
attribute schema system out there that I know of, or anyone in the ID  
Schema Working group knows of.

We can start to define attributes in the openid.net namespace and  
then reference more authorative URIs when they exist.

This would let the OpenID community define the immediately required  
attributes for people to implement and deploy AX, which will likely  
increase awareness

[1] http://openid.net/specs/identity-attribute-metadata-1_0-01.html

[2]  Of course we have all the issues of IPR etc. at the ID Schema  
working group since it would be unclear what organization would be  
managing that spec. Over here in the OpenID community we are working  
to resolve that, so perhaps the ID Schema people could participate in  
a list hosted at openid.net?

-- Dick

On 4-Apr-07, at 10:27 PM, Drummond Reed wrote:

 +1 to defining attribute identifier URIs/XRIs in the Identity  
 Commons ID
 Schemas project.

 =Drummond

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On  
 Behalf
 Of Recordon, David
 Sent: Wednesday, April 04, 2007 1:16 PM
 To: Johnny Bufu
 Cc: OpenID specs list
 Subject: RE: Moving AX Forward (WAS RE: SREG namespace URI rollback)

 Johnny,
 I see a lot of, at least my initial confusion, coming from there being
 multiple documents.  This is why I urge merging the transport and
 metadata since the reality is they currently are only being used with
 each other.  As the metadata document doesn't actually define a new
 format, rather references existing formats, I am unsure why it cannot
 just be a section in the transport document.  It is understood that  
 you
 must use the metadata format for the schema URLs in the transport, so
 the two documents really are coupled to begin with.

 I agree that you need to bootstrap a set of attributes for people  
 using
 AX.  As I have done so in the past, I'd encourage this work happen
 within the ID Schemas project (http://idschemas.idcommons.net/) versus
 defining First Name yet again for openid.net.  I have no problem with
 the spec listing a set of schema URLs, I just strongly feel that
 anything non-OpenID specific should be hosted and defined elsewhere
 since so many people have already done it.  I do understand the  
 need for
 the schema URL hosting the metadata document, which is why I am
 advocating this work be done as part of the ID Schemas project to
 provide this flexibility.

 --David

 -Original Message-
 From: Johnny Bufu [mailto:[EMAIL PROTECTED]
 Sent: Wednesday, April 04, 2007 12:39 PM
 To: Recordon, David
 Cc: Dick Hardt; OpenID specs list
 Subject: Re: Moving AX Forward (WAS RE: SREG namespace URI rollback)


 On 4-Apr-07, at 12:18 PM, Recordon, David wrote:
 One thing that I do think would be worthwhile in smoothing more of
 this SREG/AX confusion would be adding SREG support to Sxip's OpenID
 libraries.

 This is on the todo list, and judging by the interest showed by some
 contributors could happen any day now.

 Any thoughts on spec consolidation

 I think I'd propose the following:
  - Remove http://openid.net/specs/openid-attribute-
 types-1_0-02.html (I
 do not believe OpenID should define its own schema elements for  
 things

 like First Name which are not specific to OpenID, defining a URL  
 for

 an OpenID enabled URL for example I think would be fine on  
 OpenID.net)

 I understand that point of view and we were looking into determining
 what would be the best place where this spec could live.

 However, since the AX's adoption will depend (at least in the  
 beginning,
 before the metadata and automatic acquisition mechanisms are  
 finalized)
 on the participants using the same names for the attributes they
 transfer. From this point of view, I believe AX could use openid.net's
 recommendation (if endorsement is too much) to use a set of names /  
 URIs
 for the most commonly transfered attributes.
 (Kind of like what made SREG successful -- having the spec provide /
 something/ for a jump-start).

  - Merge http

Re: Moving AX Forward (WAS RE: SREG namespace URI rollback)

2007-04-05 Thread Dick Hardt

On 4-Apr-07, at 1:16 PM, Recordon, David wrote:

 Johnny,
 I see a lot of, at least my initial confusion, coming from there being
 multiple documents.  This is why I urge merging the transport and
 metadata since the reality is they currently are only being used with
 each other.  As the metadata document doesn't actually define a new
 format, rather references existing formats, I am unsure why it cannot
 just be a section in the transport document.  It is understood that  
 you
 must use the metadata format for the schema URLs in the transport, so
 the two documents really are coupled to begin with.

Actually it is describing a document format, and it could easily be  
used by other groups as evidenced by references from people in the ID  
Schemas group.


 I agree that you need to bootstrap a set of attributes for people  
 using
 AX.  As I have done so in the past, I'd encourage this work happen
 within the ID Schemas project (http://idschemas.idcommons.net/) versus
 defining First Name yet again for openid.net.  I have no problem with
 the spec listing a set of schema URLs, I just strongly feel that
 anything non-OpenID specific should be hosted and defined elsewhere
 since so many people have already done it.  I do understand the  
 need for
 the schema URL hosting the metadata document, which is why I am
 advocating this work be done as part of the ID Schemas project to
 provide this flexibility.

see my response to Drummond ...

We defined a set of attributes 6 months ago under schema.openid.net.

I think we have let other groups have time to do something, I'd like  
to get on with building and deploying stuff.

-- Dick


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


Re: Attribute Exchange 1.0 svn revision 295 review

2007-04-05 Thread Dick Hardt
On 4-Apr-07, at 2:07 PM, Josh Hoyt wrote:
 Is editing of this spec by authors of other OpenID specifications
 welcome? (I hope that by this review and my past spec work I'm showing
 that I have adequate understanding and appropriate goals.)

Yes!

Great feedback below

 Update URL issues
 =

 I assume that the update_url is intended to match the realm of the
 authentication request. The spec doesn't say this anywhere.

Good addition.


 There is no information about what form an update request will take,
 or what a response to an update request will look like. Is an update
 request supposed to be an OpenID authentication mode=id_res message?
 If so, I think this is at least a little confusing, since the
 user-agent of this HTTP transaction is not the user's browser, but the
 provider's.

The intention was that it was in the same format as the original  
message. Do you have another suggestion?


 There doesn't seem to be a way to expire an update URL or unsubscribe
 from updates.

Another good point.

Returning a 404 would be one way to expire the URL.


 There is no discussion of how an OpenID provider should behave if an
 update URL does not respond (retry? stop using that URL? some of
 each?)

That would seem to be implementation dependent as the OP is acting on  
behalf of the user, but agreed the spec should at least have a  
recommendation.


 Store Requests
 ==

 The realm in a store request is somewhat meaningless; The provider has
 no way of knowing whether the data came from something that's in that
 realm, even if a return_to URL is provided.

The realm would be a hint

 What will happen to the data when a store is requested is not
 discussed (will it replace the current value? will it get
 concatenated? Does it depend on the attribute? If it's left up to the
 provider, how will an RP know when it should initiate a store?)

It is up to the OP to manage the attributes and deal with multiple  
values since this is the user's data. Not all that different from  
what an RP does when it gets data.

An RP would initiate a store if it thinks the data will be useful to  
other RPs.


 Multiple Values
 ===

 There is no way to say I want as many of X as you have, and I don't
 care how many that is

Good point. Perhaps have  a magic value like -1 to indicate as many  
as the user will release?
I had thought the RP would likely have a maximum they would want in  
most situations.


 There is the issue that I brought up in a separate message where
 count=1 is different from not specifying a count, even though they
 both mean 1 or 0 values.

The perl way would be to have more then one way to do it and allow  
both methods to mean the same thing.

The python way would be there is one way to do it and not allow  
count=1 in a request


 The spec wording is unclear on what the count response parameter
 should be. The example shows sending back a different count, which
 suggests that the response count can be less than the request count,
 but that should be explicit.

good point


 Could we do away with unspecified count in the interests of simpler
 code everywhere? That way, we always know there's a count and the data
 is always accessed in the same way.

Are you suggesting we always send the count?
Most requests we have done only are requesting a single value, so  
that seems like lots of overhead.
Agree having one way to do it has its advantages, you are showing  
your Python roots. :-)


 It's not clear from the specification whether zero-length strings as
 values for things with a count should be treated the same as they are
 for things without a count.

Agree is is not clear.

I would suggest zero-length is the value that is returned.
If no value is to be returned, then nothing is sent.

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


Re: Moving AX Forward (WAS RE: SREG namespace URI rollback)

2007-04-05 Thread Dick Hardt

On 5-Apr-07, at 9:06 AM, Recordon, David wrote:

 Actually it is describing a document format, and it could easily be
 used
 by other groups as evidenced by references from people in the ID
 Schemas
 group.
 I agree that it could be, but is anyone?

It leaves the option open.

 I love shooting beyond the 80%
 to get the remaining 20%, but if that is just a pipe dream then I  
 have a
 hard time seeing why the documents need to be separate and thus more
 complex.

An RP does not need to worry about the metadata, so it is much easier  
for an RP to implement if they don't need to look at the other document.

I don't think this is really that important of a point given all the  
other things we need to do. People are doing to do things different  
then you would, but get the same result -- is that ok?


 We defined a set of attributes 6 months ago under schema.openid.net.
 So Dick, this is part of my problem with AX.  Sxip has defined a  
 set of
 attributes and never gained consensus on this list that that is the
 right thing to do.

We wanted to publish them on the website so that other people could  
look at them, but you did not want to do that, and you control the  
domain.




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


Re: Moving AX Forward (WAS RE: SREG namespace URI rollback)

2007-04-05 Thread Dick Hardt
If you would let us put the attributes on the website, then other  
people could see them and comment on them.

On 5-Apr-07, at 9:02 AM, Recordon, David wrote:

 I guess I don't see why blaming the ID Schemas project for not much
 happening is a good excuse for not doing it there.

Blame? ... just stating a fact.

 People who care will
 either have to drive this work within the OpenID project or the ID
 Schemas project; I fail to see how the effort required in each differs
 greatly.  In some senses, I think if people gather as part of the ID
 Schemas project and try to move this work forward, it will actually be
 more successful than trying to do it here.

People have not gathered and done work on the ID Schemas project to  
date.

People are now gathering on the OpenID list around AX -- so let's use  
that momentum.
I stated several reasons why it makes sense to do it here.


 Nothing done by OpenID in the past has intrinsically been easy  
 which is
 why I continue to think that something being hard is not a valid  
 reason
 to not do the right technical/social thing.  I know that these two
 communities can work together, but the onus is on the OpenID AX  
 side to
 make this conversation successful and drive progress.

Oh, so if we add MORE people to the mix it will be easier!!! :-)
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs


Re: Promoting OpenID

2007-04-04 Thread Dick Hardt

On 2-Apr-07, at 8:15 AM, McGovern, James F ((HTSC, IT)) wrote:

 Is anyone here working with vendors in the ERP, CRM, ECM, BPM or  
 VRM spaces such that user-centric identity is built into their  
 product?

We are working with salesforce.com ...
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs


Re: Attribute Exchange pre-draft 5

2007-04-03 Thread Dick Hardt

On 3-Apr-07, at 3:32 AM, Josh Hoyt wrote:
 If I understand correctly, the response to a request for an attribute
 with count.x=1 is different from the response for a request with no
 count specified, even though the meaning is the same.

 (namespacing left off for clarity)

 Request:

  .type.a=http://example.com/a
  .count.a=1
  .type.b=http://example.com/b

 Response:

  .type.a=http://example.com/a
  .count.a=1
  .value.a.1=avalue
  .type.b=http://example.com/b
  .value.b=bvalue

 Even though the request for a and b have equivalent meaning (send zero
 or one values for this attribute) the response MUST encode them in
 different ways. I think this is ugly, because the detail of the way
 that the attribute was requested has to be preserved in the code, to
 ensure that the response can be encoded correctly. (it's not
 sufficient to just default the count to one if it's not specified)


 Is there a reason that it's specified this way? I'd prefer if there
 was only one way to do it.

Good point. Either .count. has to be more then 1 in a request so that  
there is only one way to do it,
or the response could be in either form where .count.=1 to be  
consistent with the request being able to be in either form.


 Also, can the count be zero in the response? it seems like that's OK,
 and if it is, it'd address my concern about overloading zero-length
 strings to mean no value.

Another good point. I agree it should be able to be zero.

-- Dick

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


Re: Server-to-server channel

2007-04-03 Thread Dick Hardt
Good questions to tease out the logic behind the architecture Anders,  
responses to each of your points below ...

On 3-Apr-07, at 6:18 AM, Anders Feder wrote:

 Johnny Bufu wrote:
 This is basically a push approach, as opposed to the pull approach
 you were suggesting.

 I'm new to OpenID, and no engineer, but I have to say that I have a  
 bad
 feeling about this 'push' approach. It inverts the relationship  
 between
 client and server and seems entirely contrary to the stateless  
 spirit of
 the Web:

There are two common client server design patterns. Request /  
Response and Publish / Subscribe.


 * The RP can't know the status of the information it is working with -
 it just have to assume that the attributes it has in store are up- 
 to-date.

The RP has what ever the user last gave the RP. If the user is  
involved in the transaction, the RP may ask the user for up to date  
information.
Note that your concern is constrained to situations where the user is  
not involved.

 * If an OP fails to update an attribute, the RP will never know - no
 fall-backs can be implemented.

When the data changes, the user then decides if the RP gets the data.  
If the user did not want the RP to get, well that is what the user  
decided. This is user centric after all.

 * When updating, the OP impose a previous address structure upon the
 Web, regardless of how it is actually organized now.

The converse would be the RP imposes an address structure on the OP  
on where to get the updated data.

 * While the RP's requests the information, the OP is made responsible
 for doing the work associated with distributing it.

Well, the OP would be responsible for responding to all the myriad  
useless RP requests for updated data if a pull model.

Now the OP and RP only need to move data if the data has changed and  
the user wants to push the update to the RP.

 * The OP must donate storage space to support the distribution of
 information to RP's it has no direct interest in. A malicious RP may
 even exploit this storage space for own purposes.

The alternative would be the OP would need to donate storage to  
support which RPs are allowed to ask for data.

 * Attributes are not easily referenced to, say, sub-contractors of an
 RP. The model impose limits upon the complexity of the services  
 that may
 be derived from it.

The same flow could happen between the RP and dependent services.

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


Re: Server-to-server channel

2007-04-03 Thread Dick Hardt

On 3-Apr-07, at 8:24 AM, Dick Hardt wrote:


 On 2-Apr-07, at 11:50 AM, Chris Drake wrote:
 User Centric implies that sites don't store anything about me, and
 that whenever they need to know stuff (eg: my email), they instead  
 ask
 my OpenID server, which returns them the answer (unless I've since
 revoked permission or whatever).  Again - server-to-server (although
 this time in the reverse direction) applies here.

 I understand why you think  User Centric implies a site does not
 store anything about me.

oops

I *don't* understand why you think ...


 User Centric implies that the user is the center of the transaction.

 Server to server is so NOT User Centric!

 -- Dick

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



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


Re: Server-to-server channel

2007-04-03 Thread Dick Hardt

On 3-Apr-07, at 3:05 PM, Anders Feder wrote:

 Dick Hardt wrote:
 There are two common client server design patterns. Request /  
 Response
 and Publish / Subscribe.

 I see - I was not aware that the latter model was so well- 
 understood in
 the client/server paradigm.

 The RP has what ever the user last gave the RP. If the user is
 involved in the transaction, the RP may ask the user for up to date
 information.
 Note that your concern is constrained to situations where the user is
 not involved.

 It is, but will automated transactions not make up a significant  
 portion
 of the communications on the service-oriented Web?

 * If an OP fails to update an attribute, the RP will never know - no
 fall-backs can be implemented.

 When the data changes, the user then decides if the RP gets the data.
 If the user did not want the RP to get, well that is what the user
 decided. This is user centric after all.

 I see the merits of user-centricism, but what happens if a user do  
 want
 an RP to receive an update but the RP is unavailable?

The OP can try again later. The reverse would need to be true if the  
OP was not available when the RP wanted to get the data.


 * When updating, the OP impose a previous address structure upon the
 Web, regardless of how it is actually organized now.

 The converse would be the RP imposes an address structure on the  
 OP on
 where to get the updated data.

 And rightfully so, because the user selects his OP based on his trust
 that its address structure will not change - this is the key principle
 in OpenID.

The user can change OPs if they are using delegation.


 Well, the OP would be responsible for responding to all the myriad
 useless RP requests for updated data if a pull model.

 Good point :) In most cases you are probably right, but one can  
 imagine
 attributes, especially in futuristic scenarios, which are almost
 inherently 'pull' (like GPS data) such that translating them into
 'pushes' are immensely ineffective. But I guess 'push' is per- 
 attribute
 optional, in that case?

Who has access to my GPS data is something I will want to tightly  
control!


 information to RP's it has no direct interest in. A malicious RP may
 even exploit this storage space for own purposes.
 * The OP must donate storage space to support the distribution of

 The alternative would be the OP would need to donate storage to
 support which RPs are allowed to ask for data.

 Only if the user actually wish to restrict access - and the RP  
 would not
 have access to this storage.

I think we all learned the negative aspects of having our data  
publicly searchable with email and spam.
The FOAF camp was rolling along with the Pull model until they  
realized the issues around access control of the data.


 Anyway, I'm convinced you have thought it through. Pull relates to
 push as quantum mechanics relates to relativistic physics - but very
 often quantum mechanics is overkill.

Not sure I follow the analogy.

Push is actually much simpler then Pull for any kind of sensitive  
data, which is most of the useful attribute data.


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


Re: Web Access Management

2007-04-03 Thread Dick Hardt

Ping demoed OpenID technology at RSA.

I hear Novell and IBM are looking at supporting OpenID.

Microsoft has said they will in future products.

Oracle and CA are following OpenID.

So, yes. :-)

On 2-Apr-07, at 8:21 AM, McGovern, James F ((HTSC, IT)) wrote:

Unlike blog sites and Internet startups, many large enteprises have  
purchased Web Access Management products such as Tivoli Access  
Manager, Netegrity Siteminder, etc where authentication doesn't  
occur by embedding code into the application. Is anyone directly  
working with any of the vendors in this space to promote OpenID?




** 
***

This communication, including attachments, is
for the exclusive use of addressee and may contain proprietary,
confidential and/or privileged information. If you are not the  
intended
recipient, any use, copying, disclosure, dissemination or  
distribution is
strictly prohibited. If you are not the intended recipient, please  
notify

the sender immediately by return e-mail, delete this communication and
destroy all copies.
** 
***

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


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


Re: SREG namespace URI rollback

2007-04-03 Thread Dick Hardt
I can see an OP thinking that AX is a big step, but have a hard time  
seeing it to be that big for an RP (once there are libraries that  
support AX) ... and it is really not that much more to do AX over  
SREG for an RP.

Where you thinking OP or RP David?

-- Dick

On 3-Apr-07, at 12:17 PM, Recordon, David wrote:

 I see there being a gap between SREG and AX with nothing bridging it.
 IMHO, AX takes too large of a step for people to use it if they just
 want a few more SREG fields.  I think we need something which does
 nothing more than provide a way to extend SREG and that will solve the
 majority of problems today.

 --David

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Josh
 Hoyt
 Sent: Monday, April 02, 2007 7:16 PM
 To: Recordon, David
 Cc: Johnny Bufu; OpenID specs list
 Subject: Re: SREG namespace URI rollback

 On 4/2/07, Recordon, David [EMAIL PROTECTED] wrote:
 Sure, though I think there has also been a desire to do a bit of an
 actual rev to SREG to be more of a 1.1 version in terms of either
 explicitly supporting additional fields (such as avatar)  or allowing
 field names to be URIs themselves versus a hard-coded list of
 properties.

 -1

 SREG works because it's so dead simple. Attribute exchange is not much
 more complicated, and it lets you specifiy field names with URIs *and*
 allows you to define any attributes you see fit.

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



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


Re: Features for Future Versions

2007-04-02 Thread Dick Hardt

On 2-Apr-07, at 8:09 AM, McGovern, James F ((HTSC, IT)) wrote:

 I originally joined this list with the hopes of injecting support  
 for relationships, authorization and attestation into the  
 specification but have been somewhat disappointed. I do have the  
 following questions?

 1. Will OpenID avoid incorporating features where identity  
 selectors such as Cardspace don't support the functionality?

 2. Will OpenID always constrain itself to areas where traditional  
 PKI vendors have played (authentication) and avoid areas where PKI  
 can't tread (authorization)?

Hi James

Authentication and authorization are somewhat overloaded words and  
different people mean different things by them. I recall you sending  
out a link to a set of requirements you had helped create. The  
dynamics of this mailing list tend to support concise use case  
discussion rather delve into large documents. A concise use case of  
what you mean by Authorization may prove useful to guide the  
discussion and work.

-- Dick

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


Re: Attribute Exchange pre-draft 5

2007-04-02 Thread Dick Hardt

On 2-Apr-07, at 2:41 PM, Rowan Kerr wrote:

 On 2-Apr-07, at 5:27 PM, Josh Hoyt wrote:
 I'm thinking about differentiating between an attribute that's not
 available and an attribute that *is* available, but its value is .
 I. e. difference between a null pointer, and a pointer to an empty
 string.

 That was part of why I had the idea of adding one or two extra
 response values... to know whether a user released the attribute
 (and whether it was supported by the OP).

Personally, I don't see that much value to the RP in the RP getting  
additional information that the data was available but not released,  
and unnecessary disclosure on behalf of the user.


 By looking at the namespace RDFs for the OP as you suggested,
 the RP should be able to decide whether the value is supported
 by the OP, then if it's blank AND supported, then the only thing
 the RP can't be sure about is whether or not the user released it.

Note that AX enables an OP to dynamically support new attributes on  
the fly -- and publishing ALL available attributes for a user would  
be a privacy problem.


 If the RP really needs a value, they can prompt the user for
 it after getting the AX response and it doesn't really matter
 whether the OP supports it or not. (Unless you're going to
 maybe try and Store it back to the OP later on).

 But prompting users twice for the same value (for lack of any
 way to know the cause of a blank value) might be an annoying
 experience.

The RP has given the OP a hint that the value is required. If the  
user has instructed their OP to NOT give the value, then the RP can  
then decide what to do, and the user will likely expect to get  
prompted again.


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


Re: Version 2.0 soon final?

2007-03-26 Thread Dick Hardt

On 26-Mar-07, at 12:22 PM, Josh Hoyt wrote:

 On 3/20/07, Granqvist, Hans [EMAIL PROTECTED] wrote:
 OpenID 2.0 has been cooking for quite a while. When
 will 2.0 be FCS?

 What does FCS [1] mean?

 Josh

 1. http://en.wikipedia.org/wiki/FCS

Future Combat Systems?

http://en.wikipedia.org/wiki/Future_Combat_Systems

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


Re: Extensions key prefix

2007-03-13 Thread Dick Hardt

On 13-Mar-07, at 6:23 PM, Drummond Reed wrote:

 Rowan,

 If I understand you correctly here, what you are saying is that  
 openid.ns.*
 prefixes work almost identically to XML namespace (xmlns) prefixes,  
 i.e.:

that is where the idea came from :-)


 * the prefix is never globally defined by dynamically defined on a
 per-instance basis

... never globally defined *but* is dynamically defined ...

 * thus you don't know what the prefix is in a specific OpenID  
 message until
 you parse the message.


correct -- and good point to call it out as clearly it is not obvious  
to people -- thanks!

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


Re: Proposal: An anti-phishing compromise

2007-02-09 Thread Dick Hardt
I chatted with Avery about this today.

URIs for specific auth methods as well as ones for general seems to  
be the flexible approach.

Per Kim's laws, the method of auth may not be needed, so is extra  
disclosure


On 8-Feb-07, at 11:38 PM, Recordon, David wrote:

 Maybe laws are meant to be broken.  I don't see why a RP knowing  
 that I
 used a token as a second factor is a bad thing.  If nothing else, the
 technology should support the OP providing that information and the  
 OP's
 implementation can let me as the user decide if I want to.  Just like
 the trust request, it isn't mandated by the spec but every  
 worthwhile OP
 does it.

 My $0.02.

 --David

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
 Behalf Of Dick Hardt
 Sent: Sunday, February 04, 2007 11:42 PM
 To: Granqvist, Hans
 Cc: OpenID specs list
 Subject: Re: Proposal: An anti-phishing compromise


 On 1-Feb-07, at 2:36 PM, Granqvist, Hans wrote:
 Add a single, required, boolean field to the authentication response
 that specifies whether or not the method the OP used to authenticate
 the user is phishable. The specification will have to provide
 guidelines on what properties an authentication mechanism needs to
 have in order to be non-phishable. The field is just meant to
 indicate that the authentication mechanism that was used is not a
 standard secret entered into a Web form.

 The receiver should decide what is 'non-phishable', not the  
 sender, so

 it would be better if the OP just states what mechanism was used,
 perhaps.

 Per Kim's laws, how I authenticate to my OP is none of the RP's
 business.
 That I authenticated in a phishing resistant manner is.

 ie. we want the OP to make the statement that it followed certain
 anti-phishing guidelines.

 There is no certainty that the OP followed them, but the RP and user
 have recourse against an OP if the OP stated that it did follow the
 anti-phishing guidelines.

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



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


Re: Proposal: An anti-phishing compromise

2007-02-05 Thread Dick Hardt
Hi Josh

A few comments:

1) I think this should be an extension following previous arguments  
that AuthN Age should be an extension. (AuthN Age would be another  
good item in this extension)
This allows an OP to advertise if it supports a specific security  
profile.

2) It would be future proofing to view a phishing resistance as one  
of many security profiles. Strong Authentication could be another one.

3) The RP should be able to request that one of more security  
profiles are used. Not all RPs will require a particular profile, so  
provides a nice security gradient.

4) The phishing resistant profile should be a URI, so that new ones  
can be created in the future. The profile would not state  
specifically how authentication was done, but would set a bar on what  
needed to be done to provide a level of assurance that the user had  
not been phished. As technology advances, new security profiles will  
likely be developed, which could then be deployed, advertised by the  
OP, and requested by RPs


Summary of process:

RP does discovery on OP to see if it supports the desired security  
profile. If the profile is not supported by the OP, then the RP may  
abort the transaction and provide the user with

The RP expresses the desired security profile in the request. eg.:

openid.sp.request=http://specs.openid.net/sp/phishing-resistant-A

The OP executes on the desired security profile and states it has in  
the response. eg.:


openid.sp.response=http://specs.openid.net/sp/phishing-resistant-A

The RP checks the security profile in the response and proceeds  
accordingly.


On 1-Feb-07, at 1:41 PM, Josh Hoyt wrote:

 Hello,

 I've written up a proposal for an addition to the OpenID
 Authentication 2.0 specification that addresses the phishing problem.
 I've had some off-list discussion of it, and I think it may strike the
 right balance. Please provide feedback.

 Josh

 Background
 ==

 We have had a lot of good discussion about how phishing relates to
 OpenID. There seems to be consensus that the OpenID Authentication
 spec should address these issues, but not consensus on how that should
 happen.

 The ways that OpenID can potentially make phishing worse:

  * Redirects to your provider are a fundamental part of the flow of
 OpenID, so being redirected to a phishing site is easy to miss

  * Every relying party (necessarily) needs to know who the provider
 is in order to verify the authentication response. This means that the
 site knows what UI it needs to use to phish (and even worse, it can
 just proxy the user to the provider)

 I think these two issues cover what makes phishing potentially a
 greater threat when using OpenID.

 Although these problems are significant, if a user can authenticate to
 their OpenID provider through an non-phishable mechanism, OpenID can
 make the phishing problem *less* of a threat, because there are fewer
 places that will need to ask for credentials.

 Other relevant issues:

   * There is no universally deployed solution to the phishing problem

   * There is not even a universally *accepted* solution to the  
 phishing problem

   * Any technology that prevents phishing will require user-agent
 support or else will fundamentally change the flow of OpenID (prevent
 relying-party-initiated sign-in)

   * OpenID is intended to be deployed without requiring specific
 technologies to be present in the user-agent

   * Any general anti-phishing technology can be applied to OpenID

 Proposed Change
 ===

 Add a single, required, boolean field to the authentication response
 that specifies whether or not the method the OP used to authenticate
 the user is phishable. The specification will have to provide
 guidelines on what properties an authentication mechanism needs to
 have in order to be non-phishable. The field is just meant to
 indicate that the authentication mechanism that was used is not a
 standard secret entered into a Web form.

 Analysis
 

 This proposal is a simplification of the Assertion Quality Extension
 [1] (AQE), and is essentially the same as what Ben Laurie proposed
 earlier [2]. It does not attempt to replace the AQE or require it for
 authentication in general.

 Benefits
 

 The proposal is trivial implement, it acknowledges that phishing is a
 problem, and forces implementers think about it. If more assurances
 are required, then the AQE, whitelists, and other mechanisms still
 need to be employed. This field just sets a minimum bar.

 I think that this is the right information to require, because it
 addresses this one thing that makes OpenID potentially worse for
 security, but it does not mandate specific technologies.

 It pushes the liability for phishing relying parties to OpenID
 providers, who are the ones who should be responsible for taking
 measures to prevent phishing. IANAL, so I don't know if this has any
 real teeth, but it does make it clear to people who are 

Re: Proposal: An anti-phishing compromise

2007-02-04 Thread Dick Hardt

On 1-Feb-07, at 2:36 PM, Granqvist, Hans wrote:
 Add a single, required, boolean field to the authentication
 response that specifies whether or not the method the OP used
 to authenticate the user is phishable. The specification will
 have to provide guidelines on what properties an
 authentication mechanism needs to have in order to be
 non-phishable. The field is just meant to indicate that the
 authentication mechanism that was used is not a standard
 secret entered into a Web form.

 The receiver should decide what is 'non-phishable', not the
 sender, so it would be better if the OP just states what
 mechanism was used, perhaps.

Per Kim's laws, how I authenticate to my OP is none of the RP's  
business.
That I authenticated in a phishing resistant manner is.

ie. we want the OP to make the statement that it followed certain  
anti-phishing guidelines.

There is no certainty that the OP followed them, but the RP and user  
have recourse against an OP if the OP stated that it did follow the  
anti-phishing guidelines.

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


Re: Federated Authorization

2007-01-25 Thread Dick Hardt


On 25-Jan-07, at 1:36 PM, McGovern, James F ((HTSC, IT)) wrote:


Modify your scenario as follows:

- Tthe College of Physicians and Surgeons says she is a surgeon and  
is board certified for X number of procedures
- A particular hospital says she is part of their team. Likewise,  
they also know that she plays different roles at other hospitals.  
Minimally we want to know when her admission priveleges expire
- The university says she is part of their faculty and teachs in  
both the business school and engineering school.
- the government says she is the business owner of her surgical  
practice and also serves in a board capacity on other boards


Hopefully we can develop specifications which go deeper than just  
matching/correlation of identity and attribute.


Hi James

I don't follow your last comment. Would you elaborate?

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


Re: 2.0 Spec Questions

2007-01-22 Thread Dick Hardt

On 21-Jan-07, at 4:48 PM, James McGovern wrote:

 Several questions after reading the 2.0 spec - draft 11.

 1. The definition of realm if I am reading it correctly could be  
 problematic
 in large enterprises. For example, if one were using a web access  
 management
 product, they would have the ability to define a realm in terms of  
 a listing
 of discrete hosts that may or may not fit a URL pattern matching  
 approach.
 For example, I could have a demographic called consumers who could  
 access
 hosts such as http://myconsumer.example.com ,
 http://printstatements.example.com, http://paybills.example.com  
 Likewise
 another demographic called Business Partner may have a different  
 set of
 hosts they can interact with.

The motivation of the realm is to deal with web sites where there are  
many host names, but really one site -- LiveJournal being the  
motivating use case, as well as being where OpenID got its start.  
Each blog has a separate hostname:

dick.livejournal.com
brad.livejournal.com

Since different blogs have different hostnames, but a user thinks of  
them all as being lLiveJournal, so being able to have a realm of:

*.livejournal.com


 2. In terms of checking the nonce, can we recommend that a deployment
 practice should be to use the NTP protocol and point to clocks of a  
 certain
 stratum? Likewise, would it be a good idea if an association could  
 indicate
 how much skew it would accept before rejecting?

The date-time stamp in the nonce is really to assist the RP in  
knowing that it can discard a message if it is older then a x period  
rather then having to hold every nonce received. I don't know how  
much skew happens out in the wild these days, but perhaps we could  
get an idea of what that is and then recommend how long the RP should  
keep a nonce before discarding?


 3. In terms of an extension, should an OP be able to indicate when  
 reauth
 may be required so the user doesn't assume that if they  
 authenticate once
 they are always good?

AuthN is for the benefit of the RP.  While one view might be that the  
OP should be able to dictate how long the AuthN is good for, once  
used, it is really the RP that is determining if it is the same user.

I think the more important consideration is the RP wanting to get the  
OP to do AuthN for the user instead of using a cached AuthN. I wanted  
to put it in the spec, but the decision was that it was better in an  
extension.


 4. Some portions of the spec are heavily coupled to PKI. How should  
 growing
 users of IBE think of this?

Besides recommending sites use TLS, I don't see the PKI coupling you  
are referring to. Would you elaborate?
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs


Re: [OpenID] Announcing OpenID Authentication 2.0 - Implementor's Draft 11

2007-01-19 Thread Dick Hardt

On 19-Jan-07, at 6:19 AM, Ben Laurie wrote:


 Still totally unhappy about the phishing issues, which I blogged  
 about here:

 http://www.links.org/?p=187

There are numerous ways of solving this. Several standard methods can  
solve it. It is a relationship between the user and the OP and the RP  
is not party, so I don't think it belongs in the OpenID  
Authentication specification.

That does not mean it is not important, just that *this* spec is not  
the right place.

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


DRAFT 11 - FINAL?

2007-01-18 Thread Dick Hardt
Hey List

To deal with the recent security concern postings about OpenID,  
language was added to clarify a secure channel is needed between the  
OP and the end-user's machine.

Are there any more issues with this specification:

http://openid.net/specs/openid-authentication-2_0-11.html

Can we make this final?

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


Re: Federated Authorization

2007-01-18 Thread Dick Hardt

Hi James

As Phillip states, SAML can be used to represent the assertion.

Interesting that you mention a Doctor example. A use case that we are  
working on uses a Surgeon (Sally) who needs to prove:


- Tthe College of Physicians and Surgeons says she is a surgeon
- A particular hospital says she is part of their team
- The university says she is part of their faculty
- the government says she is the business owner of her surgical practice

With OpenID, each of these authorities could make a claim about  
Sally's OpenID. This could be expressed as a SAML assertion.


When accessing a resource that requires one of Sally's verified  
attributes, Sally (using her OP) proves she is a specific OpenID  
Idenitifier and also provides the SAML assertion(s) that prove that  
identifier has been verified to belong to a surgeon, team member,  
faculty member, business owner.


We have created an example for something anyone on the net can have  
verified, their email address. I'll post separately about that.


-- Dick

On 18-Jan-07, at 8:51 AM, McGovern, James F ((HTSC, IT)) wrote:

I would love to see folks hear that also blog not only continue to  
discuss federated identity but also consider of the course of  
several additional postings also talk about the need for federated  
authorization. Consider an example where a Doctor in a hospital is  
having an electronic interaction with a healthcare insurance  
provider. The hospital should be the identity provider while the  
entity that licensed the Doctor for given sets of practices should  
be responsible for certain forms of authorization.


If we only talk about identity without authorization, the  
conversation will result in lots of great software where folks who  
create them won't make any money since consumer-centric  
interactions have volume without corresponding revenue.




** 
***

This communication, including attachments, is
for the exclusive use of addressee and may contain proprietary,
confidential and/or privileged information. If you are not the  
intended
recipient, any use, copying, disclosure, dissemination or  
distribution is
strictly prohibited. If you are not the intended recipient, please  
notify

the sender immediately by return e-mail, delete this communication and
destroy all copies.
** 
***

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


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


Re: DRAFT 11 - FINAL?

2007-01-18 Thread Dick Hardt
OK -- would it be possible to keep the list apprised of the progress  
and post the issue and resolution once you are done this afternoon?

-- Dick

On 18-Jan-07, at 3:55 PM, Recordon, David wrote:

 Considering draft 11 hasn't been published yet, I don't see how we can
 make it final at this point.  In addition, the file you link to is  
 a few
 patches old.  While I appreciate your enthusiasm, Josh, Johnny, and  
 I do
 have a process to this madness.

 I know you know that we're really close, there is one remaining issue
 Josh, Drummond, and I are tackling this afternoon, and then we'll
 publish draft 11.

 Thanks,
 --David

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
 Behalf Of Dick Hardt
 Sent: Thursday, January 18, 2007 3:45 PM
 To: specs@openid.net
 Subject: DRAFT 11 - FINAL?

 Hey List

 To deal with the recent security concern postings about OpenID,  
 language
 was added to clarify a secure channel is needed between the OP and the
 end-user's machine.

 Are there any more issues with this specification:

   http://openid.net/specs/openid-authentication-2_0-11.html

 Can we make this final?

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



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


Re: Announcing OpenID Authentication 2.0 - Implementor's Draft 11

2007-01-18 Thread Dick Hardt
Great job David, Johnny and Josh!

-- Dick

On 18-Jan-07, at 7:35 PM, Recordon, David wrote:

 So with great pleasure I get to announce the culmination of about nine
 months of work between the OpenID, XRI, Sxip, and LID communities  
 in the
 drafting of OpenID Authentication 2.0.  This evening the editors have
 published the final draft of the spec, which we now feel is in a solid
 state for public implementations.

 There are already implementations in various languages
 (http://svn.apache.org/repos/asf/incubator/heraldry/libraries/,
 http://code.google.com/p/openid4java/,
 http://code.google.com/p/openid4perl/) supporting this spec and more
 will emerge over the next few weeks.

 There will be another draft of the spec before it is considered final,
 though unless unforeseen implementation problems emerge these changes
 will be further wordsmithing and cleanup.

 http://openid.net/specs/openid-authentication-2_0-11.html (dated  
 today)

 Cool? Cool!

 --David



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


Re: Announcing OpenID Authentication 2.0 - Implementor's Draft 11

2007-01-18 Thread Dick Hardt
David

A couple questions:

1) Would you like to set a deadline for final comments? Perhaps a week?

2) What is the approval process now? Is it still as posted at:

http://openid.net/specs.bml

Currently, the collective authors of OpenID Authentication (David  
Recordon, Josh Hoyt, Dick Hardt, and Brad Fitzpatrick) oversee this  
process and make the final determination of when a proposal has  
matured.

-- Dick

On 18-Jan-07, at 7:35 PM, Recordon, David wrote:

 So with great pleasure I get to announce the culmination of about nine
 months of work between the OpenID, XRI, Sxip, and LID communities  
 in the
 drafting of OpenID Authentication 2.0.  This evening the editors have
 published the final draft of the spec, which we now feel is in a solid
 state for public implementations.

 There are already implementations in various languages
 (http://svn.apache.org/repos/asf/incubator/heraldry/libraries/,
 http://code.google.com/p/openid4java/,
 http://code.google.com/p/openid4perl/) supporting this spec and more
 will emerge over the next few weeks.

 There will be another draft of the spec before it is considered final,
 though unless unforeseen implementation problems emerge these changes
 will be further wordsmithing and cleanup.

 http://openid.net/specs/openid-authentication-2_0-11.html (dated  
 today)

 Cool? Cool!

 --David



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


Re: Announcing OpenID Authentication 2.0 - Implementor's Draft 11

2007-01-18 Thread Dick Hardt
Hi Daniel

The OpenID4java code is up to date to DRAFT 11, and also has support  
for the OpenID Attribute Exchange draft.

(Sxip volunteered to build the OpenID Java libraries, and our  
preference was to use code.google.com for the repository)

-- Dick

On 18-Jan-07, at 11:52 PM, Daniel E. Renfer wrote:

 I'm a little confused. You list Heraldry as being OpenID Auth 2.0
 enabled, but looking at the SVN logs it seems like only the python
 library has been seeing activity. (And all of that in a flood of
 commits)

 Is there any word on when we will see the rest of the libraries
 brought up to spec? I'm looking for Java support in particular. Will
 there be many major changes upgrading from the current code to the
 Auth2.0 code?

 I want to code my site (still in private development) to be 2.0
 friendly from the get go, but I'm not sure if I should be using the
 openid4java code or wait for Heraldry to be updated.

 -- 
 Daniel E. Renfer
 http://kronkltd.net/


 On 1/18/07, Recordon, David [EMAIL PROTECTED] wrote:
 So with great pleasure I get to announce the culmination of about  
 nine
 months of work between the OpenID, XRI, Sxip, and LID communities  
 in the
 drafting of OpenID Authentication 2.0.  This evening the editors have
 published the final draft of the spec, which we now feel is in a  
 solid
 state for public implementations.

 There are already implementations in various languages
 (http://svn.apache.org/repos/asf/incubator/heraldry/libraries/,
 http://code.google.com/p/openid4java/,
 http://code.google.com/p/openid4perl/) supporting this spec and more
 will emerge over the next few weeks.

 There will be another draft of the spec before it is considered  
 final,
 though unless unforeseen implementation problems emerge these changes
 will be further wordsmithing and cleanup.

 http://openid.net/specs/openid-authentication-2_0-11.html (dated  
 today)

 Cool? Cool!

 --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: Question on Conferences and the Marketing of OpenID

2007-01-14 Thread Dick Hardt

On 8-Jan-07, at 7:01 AM, James McGovern wrote:

 I learned of OpenID because I ran across it while blogging.  
 Otherwise, in
 context of my day job working for a Fortune 100 enterprise whose  
 primary
 business model isn't technology otherwise would have never heard of  
 it.
 While this list is to discuss specifications, this begs the  
 question of
 should we create specifications around how to get the word out  
 better to all
 of my industry peers.

 Noticed that folks from Verisign were key players in the creation  
 of this
 spec, yet it is not prominently mentioned on their web site. If you  
 know to
 search for it, it still only returns two results. What do we need  
 to do to
 get Verisign and the other large guys (small guys are covered) to  
 show a
 little more respect towards OpenID in terms of their own web site?

Good question for VeriSign!


 I ran across The : Authentication and Online Trust Alliance and their
 upcoming conference (http://www.aotalliance.org/summit2007/) and  
 noted that
 no one is talking about stuff in our space. Does anyone have a list  
 of all
 planned 2007 conferences where OpenID should be discussed?

I don't have ALL conferences, but here are some that I known of:

Catalyst, Digital ID World, Gartner IdM.

Additionally, there are the Web 2.0 and O'Reilly Emerging tech  
conferences.

I am speaking at a couple of CERT conferences and the W3C conference  
as well as a couple European IdM conferences.


 Also curious if anyone has been pushing the industry analyst crowd to
 provide coverage? If not, I will need lots of folks to start  
 submitting
 inquiries to Gartner, Forrester and the Burton Group to get them to  
 pay
 attention.

I have briefed Gartner, Forrester and the Burton Group on OpenID and  
the user-centric model.

User-centric identity was discussed in several presentations at the  
last Catalyst conference. At that time, SXIP/DIX and OpenID had not  
converged and DIX had more prominence.

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


Re: Business Scenarios

2007-01-14 Thread Dick Hardt
We are working on a citizen-centric solution for regional set of  
public sector organizations. Most of the major IdM vendors are  
involved, but no white papers have been published at this time.


-- Dick

On 10-Jan-07, at 8:42 AM, McGovern, James F ((HTSC, IT)) wrote:

I am looking for any generic whitepapers targeted at any vertical  
that outline a business scenario (not the usual consumer- 
orientation) where user-centric identity has either been deployed  
or at least discussed. Also would love to know of situations in  
which user-centric identity displaced PKI based implementations.


If something exists in this space but hasn't been written up, maybe  
I could task several industry analysts to provide coverage.



** 
***

This communication, including attachments, is
for the exclusive use of addressee and may contain proprietary,
confidential and/or privileged information. If you are not the  
intended
recipient, any use, copying, disclosure, dissemination or  
distribution is
strictly prohibited. If you are not the intended recipient, please  
notify

the sender immediately by return e-mail, delete this communication and
destroy all copies.
** 
***

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


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


Re: Attribute Exchange Schema site

2007-01-05 Thread Dick Hardt
Hi Rowan

We will be releasing a tweaked version of the Attribute Exchange spec  
tomorrow. Adds a simple way to support requested and receiving  
multiple values for the same type.

The old properties list is here: (there is a link to archives at the  
bottom of the specs page on OpenID.net)
http://openid.net/specs/openid-attribute-properties-list-1_0-01.html

We now a document for each property that has RDF so that it is both  
programatically readable and human readable. Just need to decide the  
domain to put them!

The Attribute Type model is such that anyone with a domain can define  
new attributes. No need for central control. We created a set of what  
we thought were common attributes, but that does not mean anyone has  
to use them.

Glad to hear someone is spending more time implementing that  
discussing. ;-)

-- Dick
On 4-Jan-07, at 12:49 PM, Rowan Kerr wrote:

 On 1/3/07, Dick Hardt [EMAIL PROTECTED] wrote:
 Our proposal was to have the schemas for OpenID hosted at
 schema.openid.net. Some people expressed concerns about having them
 be on openid.net.

 Do you have any suggestions? Anyone else have an opinion? Does anyone
 care? ;-)

 Being part of the OpenID specs, it would make sense to me to have them
 hosted under the OpenID domain. (While a centralized, shared list of
 properties would be great in the long run, who knows how long it could
 take to get agreement from something like idcommons). Really, I don't
 particularly mind if they're even hosted anywhere at the moment as
 long as the list of properties is well defined.

 We've implemented a OP at my.standardradio.com that supports OpenID 2
 and the Draft 1 version of AX properties, and I'm in the middle of
 writing documentation for our 3rd party clients on how to work with
 our site so I was hoping to be able to update it to the latest version
 of the spec before sending out documentation that is already behind
 the times.

 Failing a solid list of AX Draft 2 properties, is the Draft 1
 documentation still online somewhere?


 There is a schema effort over at http://idschemas.idcommons.net/ --
 but discussion over there has been minimal to date, but perhaps this
 can jump start things ...

 I'll check that out, I remember when it was announced but never
 followed up on how any of that was progressing.


 btw: nice to see a fellow Canuck on the list!

 Glad to be here! I've been on for a while but not had cause to jump
 into the discussions much. Too busy implementing... :)

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



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


OpenID Signed Assertions 1.0 - Draft 1

2006-12-03 Thread Dick Hardt
tions of that
	document were re-used for this one.
  


TOC
12.
References


TOC
12.1.Normative References

[OASIS.saml-conformance-2.0-os]
Mishra, P., Philpott, R., and E. Maler, Conformance Requirements for the Security Assertion Markup Language
	  (SAML) V2.0, OASIS Standardsaml-conformance-2.0-os, March2005.
[OASIS.saml-core-2.0-os]
Cantor, S., Kemp, J., Philpott, R., and E. Maler, Assertions and Protocol for the OASIS Security Assertion Markup Language
	  (SAML) V2.0, OASIS Standardsaml-core-2.0-os, March2005.
[OASIS.saml-profiles-2.0-os]
Hughes, J., Cantor, S., Hodges, J., Hirsch, F., Mishra, P., Philpott, R., and E. Maler, Profiles for the OASIS Security Assertion Markup Language
	  (SAML) V2.0, OASIS StandardOASIS.saml-profiles-2.0-os, March2005.
[OpenID.attribute-exchange-1.0]
Hardt, D., OpenID Attribute Exchange 1.0 - Draft 03, November2006 (TXT, HTML).
[OpenID.authentication-2.0]
Recordon, D., Hoyt, J., Fitzpatrick, B., and D. Hardt, OpenID Authentication 2.0 - Draft 10, August2006 (TXT, HTML).
[RFC2119]
Bradner, S., Key words for use in RFCs to Indicate Requirement Levels, BCP14, RFC2119, March1997 (TXT, HTML, XML).
[RFC3280]
Housley, R., Polk, W., Ford, W., and D. Solo, Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, RFC3280, April2002.
[RFC3548]
Josefsson, S., The Base16, Base32, and Base64 Data Encodings, RFC3548, July2003.
[W3C.REC-xmldsig-core-20020212]
Solo, D., Eastlake, D., and J. Reagle, XML-Signature Syntax and Processing, W3C Recommendationhttp://www.w3.org/TR/2002/REC-xmldsig-core-20020212, February2002.



TOC
12.2.Informative References

[OASIS.saml-glossary-2.0-os]
Hodges, J., Philpott, R., and E. Maler, Glossary for the Security Assertion Markup Language
	  (SAML) V2.0, OASIS Standardsaml-glossary-2.0-os, March2005.
[OpenID.attribute-types-1.0]
Hardt, D., OpenID Attribute Types - Draft 02, November2006 (TXT, HTML).



TOC
Author's Address


Dick Hardt

Sxip Identity

798 Beatty Street

Vancouver, BC  V6B 2M1

CA
Email:
[EMAIL PROTECTED]
URI:
http://sxip.com/


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


Re: OpenID Authentication 2.0 Pre-Draft 11 (Take 5)

2006-11-25 Thread Dick Hardt

On 25-Nov-06, at 12:10 AM, Recordon, David wrote:

 Decent number of changes to help clean-up the draft from what I posted
 on the 19th.  Getting close with only a few more things left on the
 punch list!

Thanks for posting David. What do we have left on the list?

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


Attribute Exchange, Attribute Types and Attribute Metadata

2006-11-24 Thread Dick Hardt
Below is a summary of draft specifications for OpenIDAttribute  
Exchange, Attribute Types and Attribute Metadata.
I will check them into SVN real-soon-now and hopefully David will  
have them linked off the spec site.
HTML versions will be posted as separate emails for those in the US  
unable to fall asleep eating too much turkey!

Additionally, if anyone is interested in being a co-editor, please  
let me know!

-- Dick

+++

OpenID Attribute Exchange is an OpenID service for exchanging identity
information between endpoints.  Messages for retrieval and storage of
identity information are provided.  Attribute types for a variety of
different identity properties have been defined, and additional types
may be defined by any interested parties.

The creation of new attributes in the openid.net name space is outlined
in the new OpenID Attribute Types document, and involves submitting
proposals for new types to a [EMAIL PROTECTED] mailing list that we
hope to create.  Although it means yet another OpenID mailing list, it
will confine type related traffic away from more general discussion on
the main specification list.  Note that this process only applies to
attributes defined in the schema.openid.net name space, and users
are free to define their own attribute types in other name spaces.

The previous list of attribute types has been turned into a set of
metadata documents describing each type, which will be posted to a new
web server at schema.openid.net.  A new document, Identity Attribute
Metadata has been created outlining a proposed metadata format for
attribute types.

The idea behind the metadata format is that each attribute type
identifier is a URL that resolves to the metadata describing the type.
This way, attribute types may be requested without their format or
other information about them being hard coded in OP or RP
applications.  The metadata includes localized labels and text
descriptions, data format descriptions, and information on authority,
acquisition and cross referencing.  The type information is encoded in
XML for easy parsing, and is supplied with an XSL style sheet for a
human readable translation.

Document Changes

The third draft of the Attribute Exchange document incorporates a
series of changes based on community input and the progress of the
OpenID Authentication 2.0 draft document.  Chief among these changes
has been an update to the way the fetch response message, the
parameters of which now are incorporated into the openid name space.

Other minor changes were made to clarify some points and to
incorporate suggestions made by the implementation team:
* Attribute name changed to attribute type identifier
* Updated references to Attribute Types document
* Added multiple alias support to required and if_available
   parameters
* Extended examples to include multiple aliases
* Additional documentation of the fetch response message
* Additional documentation of the store response messages

The Attribute Properties document, with the list of attribute
properties, has been eliminated in favour of an Attribute Types
document that outlines the process to define new types in the
schema.openid.net name space.  This will encourage more community
participation in defining new types.

Comments and suggestions on how to can improve these specifications
are always welcome!


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


OpenID Attribute Types Draft 2

2006-11-24 Thread Dick Hardt
type will be moved
	into the non-experimental name space and the [EMAIL PROTECTED] list notified.
	  


  


	The approval stage of the process is deliberately vague; the idea
	being that a more detailed process will emerge as more interested
	parties take part.  In any case, approval should be the default action
	if there is no vocal disapproval and the proposed type is not a
	duplicate of an existing type.
  


TOC
4.2.
New Attribute Data Format Process


	  New attribute data format types are proposed and approved in
	  a similar manner to attribute types themselves.  The
	  proposed type is sent to the list expressed in XML Schema
	  ([W3C.RECxmlschema220041028] (Biron, P. and A. Malhotra, XML Schema Part 2: Datatypes Second Edition, October2004.)) format as
	  outlined in [identityattributemetadata1.0] (Hardt, D., Identity Attribute Metadata, October2006.).  Often format
	  type proposals will accompany an attribute type proposal; in
	  this case it is acceptable to combine the two proposals.
	


	


	The first step in proposing a new attribute format type is to
	search the list of existing types for similar types.
	Duplication of format types should be avoided.
	  


	Post an "intent to define" message to the mailing list at
	[EMAIL PROTECTED]  The email should describe the proposed
	type in general terms.  Posting this to the list will
	reduce duplicated effort in the case of multiple parties
	defining similar types.  Intent posts will also generate
	discussion that may be used to determine if it is
	worthwhile to pursue the proposal.
	  


	The format type should be completely described both in
	regular prose and in the meta-data format defined in [identityattributemetadata1.0] (Hardt, D., Identity Attribute Metadata, October2006.).
	  


	Post a "proposed format type" message to the mailing list
	at [EMAIL PROTECTED],
	including the motivation, description and meta-data.  An
	administrator will post the attribute type meta-data to
	the experimental http://openid.net/type/x/ area.
	  


	Discussions on the list will dictate whether or not the
	proposal passes.  If the consensus is that the proposed
	format type is worth pursuing, the type will be moved
	into the non-experimental name space and the [EMAIL PROTECTED] list notified.
	  


  


TOC
4.3.
Attribute Type Identifiers


	Attribute type identifiers should be created with the
	following considerations:
	


	Attribute type identifiers MUST conform to the generic URI
	syntax described in [RFC2396] (Berners-Lee, T., Fielding, R., and L. Masinter, Uniform Resource Identifiers (URI): Generic Syntax, August1998.).
	  


	The OpenID authority portion of the URI is schema.openid.net.
	  


	Each URI resolves to an RDF representation of the type's
	meta-data as defined in [identityattributemetadata1.0] (Hardt, D., Identity Attribute Metadata, October2006.).
	  


	URIs should, where possible, re-use existing paths in the
	schema.openid.net namespace.
	  


	The URI path should be kept as short as possible.
	  


	URI fragment specifiers should not be used.
	  


  


TOC
5.
References


TOC
5.1.Normative References

[OpenID.attribute-exchange-1.0]
Hardt, D., OpenID Attribute Exchange, August2006 (TXT, HTML).
[OpenID.authentication-2.0]
Recordon, D., Hoyt, J., and B. Fitzpatrick, OpenID Authentication 2.0 - Draft 08, August2006 (TXT, HTML).
[W3C.REC-xmlschema-2-20041028]
Biron, P. and A. Malhotra, XML Schema Part 2: Datatypes Second Edition, World Wide Web Consortium RecommendationREC-xmlschema-2-20041028, October2004 (HTML).
[identity-attribute-metadata-1.0]
Hardt, D., Identity Attribute Metadata, October2006 (TXT, HTML).



TOC
5.2.Non-normative References

[RFC2396]
Berners-Lee, T., Fielding, R., and L. Masinter, Uniform Resource Identifiers (URI): Generic Syntax, RFC2396, August1998 (TXT, HTML, XML).



TOC
Author's Address


Dick Hardt

Sxip Identity

798 Beatty Street

Vancouver, BC  V6B 2M1

CA
Email:
[EMAIL PROTECTED]
URI:
http://sxip.com/


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


Identity Attribute Metadata Draft 1

2006-11-24 Thread Dick Hardt
  directive pointing to an XSL template that translates the
	  metadata into a human readable format.
	


TOC
3.2.1.
Standard Predicates


	The standard predicates that MUST be in all metadata
	records are:
	

http://www.w3.org/1999/02/22-rdf-syntax-ns#type

		The rdf:type predicate has as its object the XML
		Schema data type or a type defined as per Section3.1 (Data Format Types).
	  

http://www.w3.org/2000/01/rdf-schema#label

		The label is a short description of the attribute
		type.  XML provides an xml:lang attribute that can be
		used on this element to provide a way to describe the
		language as per [RFC4646] (Phillips, A. and M. Davis, Tags for Identifying Languages, September2006.) used for the
		content of the element.  Using language
		tagging in this way, multiple labels can be
		provided for localization purposes.
	  

http://www.w3.org/2000/01/rdf-schema#comment

		The rdfs:comment element is used to provide a long
		textual description of the attribute type.  As for the
		rdf:label element, multilingual documentation is
		supported by the language tagging feature of RDF literals.
	  


	  


TOC
3.2.2.
Supplemental Predicates


	These predicates are optional and MAY be included in
	metadata records:
	

http://schema.openid.net/metadata#example

		Example value data for the attribute type.
	  

http://www.w3.org/2000/01/rdf-schema#seeAlso

		Indicates a resource that might provide additional
		information about the subject attribute type.
	  

http://schema.openid.net/metadata#acquisition

		The object of this predicate is a URL from which the
		IdO may be acquired.  Multiple URLs may be specified.
		The acquisition mechanism is not specified, but would
		be retrieved using a discovery mechanism specific to
		the protocol being used.
	  

http://schema.openid.net/metadata#authority

		Except in the case of a self-asserted IdO, a list of
		authority URIs for asserted claims is necessary. Each
		URI is that of an assertion authority that is allowed
		to make the IdO claim.
	  


	  


TOC
3.2.3.
Example


	  A brief example of the standard predicates and the
	  openid:example element as applied to the http://schema.openid.net/namePerson/first
	  attribute type.
	


?xml version="1.0"?
?xml-stylesheet type="text/xsl" href=""?
rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
  xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
  xmlns:openid="http://schema.openid.net/metadata#"
rdf:Description rdf:about="http://schema.openid.net/namePerson/first"
  rdfs:label
First name
  /rdfs:label
  rdfs:comment
First or given name of subject
  /rdfs:comment
  openid:example
John
  /openid:example
  rdf:type
  rdf:resource="http://www.w3.org/2001/XMLSchema#normalizedString"/
  openid:acquisition
  rdf:resource="http://example.gov/id"/
/rdf:Description
/rdf:RDF



TOC
4.
Future Directions


	Additional metadata information may be added as more complex
	attribute types are constructed.  The following sections
	outline possible extensions to the existing simple type
	definitions.
  


TOC
4.1.
Compound Properties


	  The IdO may also be composed of an aggregate of other IdO
	  types, in which case the aggregate IdO URIs will be
	  referenced.
	


TOC
4.2.
Equivalents


	  An IdO may make a claim that is equivalent to the claim of
	  an IdO of a different type. The equivalent IdO types are
	  listed in this section.
	


	  An IdO may be transformed to one of a different type if it
	  is listed as an equivalent. This property is not
	  commutative.
	


	  This information may be extended to include translation
	  mechanisms between format types. A richer transform
	  specification would allow claims to be made based on a
	  broader equivalence domain.
	


TOC
4.3.
Higgins Ontology Predicates


	  The Higgins project has created a base ontological
	  vocabulary at [HigginsOntology] (Trevithick, P., Higgins Ontology v1.10, October2006.).  Use of
	  this vocabulary allows for the integration of the attribute
	  types into a broader catalog.
	


TOC
5.
References


TOC
5.1.Normative References

[OpenID.attribute-exchange-1.0]
Hardt, D., OpenID Attribute Exchange, August2006 (TXT, HTML).
[RFC2119]
Bradner, S., Key words for use in RFCs to Indicate Requirement Levels, BCP14, RFC2119, March1997 (TXT, HTML, XML).
[RFC4646]
Phillips, A. and M. Davis, Tags for Identifying Languages, BCP47, RFC4646, September2006.
[W3C.REC-xmlschema-2-20041028]
Biron, P. and A. Malhotra, XML Schema Part 2: Datatypes Second Edition, World Wide Web Consortium RecommendationREC-xmlschema-2-20041028, October2004 (HTML).



TOC
5.2.Informative References

[Higgins-Ontology]
Trevithick, P., Higgins Ontology v1.10, October2006.



TOC
Author's Address


Dick Hardt

Sxip Identity

798 Beatty Street

Vancouver, BC  V6B 2M1

CA
Email:
[EMAIL PROTECTED]
URI:
http://sxip.com/


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


Identity Attribute Metadata Draft 1

2006-11-24 Thread Dick Hardt
 for Identifying Languages,” September 2006.) used for  
the content of the element. Using language tagging in this way,  
multiple labels can be provided for localization purposes.

http://www.w3.org/2000/01/rdf-schema#comment
The rdfs:comment element is used to provide a long textual  
description of the attribute type. As for the rdf:label element,  
multilingual documentation is supported by the language tagging  
feature of RDF literals.



 TOC
3.2.2.  Supplemental Predicates

These predicates are optional and MAY be included in metadata records:

http://schema.openid.net/metadata#example
Example value data for the attribute type.
http://www.w3.org/2000/01/rdf-schema#seeAlso
Indicates a resource that might provide additional information about  
the subject attribute type.

http://schema.openid.net/metadata#acquisition
The object of this predicate is a URL from which the IdO may be  
acquired. Multiple URLs may be specified. The acquisition mechanism  
is not specified, but would be retrieved using a discovery mechanism  
specific to the protocol being used.

http://schema.openid.net/metadata#authority
Except in the case of a self-asserted IdO, a list of authority URIs  
for asserted claims is necessary. Each URI is that of an assertion  
authority that is allowed to make the IdO claim.



 TOC
3.2.3.  Example

A brief example of the standard predicates and the openid:example  
element as applied to the http://schema.openid.net/namePerson/first  
attribute type.



?xml version=1.0?
?xml-stylesheet type=text/xsl href=schema.xslt?
rdf:RDF xmlns:rdf=http://www.w3.org/1999/02/22-rdf-syntax-ns#;
  xmlns:rdfs=http://www.w3.org/2000/01/rdf-schema#;
  xmlns:openid=http://schema.openid.net/metadata#;
rdf:Description rdf:about=http://schema.openid.net/namePerson/first;
  rdfs:label
First name
  /rdfs:label
  rdfs:comment
First or given name of subject
  /rdfs:comment
  openid:example
John
  /openid:example
  rdf:type
  rdf:resource=http://www.w3.org/2001/XMLSchema#normalizedString/
  openid:acquisition
  rdf:resource=http://example.gov/id/
/rdf:Description
/rdf:RDF


 TOC
4.  Future Directions

Additional metadata information may be added as more complex  
attribute types are constructed. The following sections outline  
possible extensions to the existing simple type definitions.



 TOC
4.1.  Compound Properties

The IdO may also be composed of an aggregate of other IdO types, in  
which case the aggregate IdO URIs will be referenced.



 TOC
4.2.  Equivalents

An IdO may make a claim that is equivalent to the claim of an IdO of  
a different type. The equivalent IdO types are listed in this section.


An IdO may be transformed to one of a different type if it is listed  
as an equivalent. This property is not commutative.


This information may be extended to include translation mechanisms  
between format types. A richer transform specification would allow  
claims to be made based on a broader equivalence domain.



 TOC
4.3.  Higgins Ontology Predicates

The Higgins project has created a base ontological vocabulary at  
[Higgins‑Ontology] (Trevithick, P., “Higgins Ontology v1.10,”  
October 2006.). Use of this vocabulary allows for the integration of  
the attribute types into a broader catalog.



 TOC
5.  References


 TOC
5.1. Normative References

[OpenID.attribute-exchange-1.0]	Hardt, D., “OpenID Attribute  
Exchange,” August 2006 (TXT, HTML).
[RFC2119]	Bradner, S., “Key words for use in RFCs to Indicate  
Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML).
[RFC4646]	Phillips, A. and M. Davis, “Tags for Identifying  
Languages,” BCP 47, RFC 4646, September 2006.
[W3C.REC-xmlschema-2-20041028]	Biron, P. and A. Malhotra, “XML  
Schema Part 2: Datatypes Second Edition,” World Wide Web Consortium  
Recommendation REC-xmlschema-2-20041028, October 2004 (HTML).


 TOC
5.2. Informative References

[Higgins-Ontology]	Trevithick, P., “Higgins Ontology v1.10,”  
October 2006.


 TOC
Author's Address

Dick Hardt
Sxip Identity
798 Beatty Street
Vancouver, BC V6B 2M1
CA
Email:  [EMAIL PROTECTED]
URI:http://sxip.com/
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs


Re: OpenID Auth 2.0 and user-agent neutrality (or, OpenID with REST/SOAP)

2006-11-19 Thread Dick Hardt

On 19-Nov-06, at 3:08 PM, Adam Nelson wrote:

 Great start on the Wiki. Note that there are some efforts in IETF for
 enhancing what can be done at the TLS layer for authentication which
 would enable the same mechanism to be used not only for HTTP, but for
 SMTP, POP3, IMAP ...

 Hmm, that's intriguing; I wasn't aware of that.  Do you have a pointer
 to some work product?

It was the direction a number of people in the HTTP-AUTH and DIX list  
were looking at going. Have not heard of an updated status since the  
last IETF, sorry.


 Also, most REST implementations have a process for acquiring a token,
 and then including that token in the XML message. What do you think
 of tweaking the existing OpenID Authentication response so that the
 RP returns a token for use in later calls?

 Interesting.  So, you're suggesting the owner of an identity provision
 an API key interactively using the existing authentication mechanism,
 and subsequent non-interactive REST API calls would use this API key
 to authenticate?  Or am I misunderstanding?

You are understanding.

 I had considered that, and it would certainly work, but what I found
 unfortunate about that arrangement is that the authentication of the
 identity is decoupled from the API calls themselves, so the user
 couldn't, for example, revoke permission to use her identity with that
 API, since an API key would already be provisioned.  Of course, the
 API keys could have expiration dates, but that opens up its own
 usability problems.

Note that revocations are challenging to implement. :-)


 I guess another way to look at it is that the API key is conceptually
 equivalent to a cookie used by an RP to preserve authentication state
 with the user agent.  The difference to my mind is that, when the
 cookie expires, the user can reauthenticate, so an expiration of 30 or
 60 minutes is probably reasonable, but when an API key expires, the
 user agent has no way to re-authenticate without parsing some HTML and
 composing a POST to the IdP, which is the arrangement I'm hoping to
 avoid.

Unless I am missing something, the user needs to be part of the  
process of generating a token regardless.

Will you be at IIW? This would be a great session there.

-- Dick

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


Re: OpenID Auth 2.0 and user-agent neutrality (or, OpenID with REST/SOAP)

2006-11-17 Thread Dick Hardt

On 17-Nov-06, at 10:38 AM, John Kemp wrote:

 Dick Hardt wrote:
 On 16-Nov-06, at 11:41 PM, Matt Pelletier wrote:
 On Nov 17, 2006, at 1:24 AM, Dick Hardt wrote:

 Hi John

 So that a message can be more then 2K of data.


 Is it possible to update the language so 1) we don't deprecate HTTP
 redirects and 2) the form redirect method is described as the
 preferred/recommended approach, but is not required? You could even
 stress that HTTP redirects should only be used when the HTTP  
 client's
 capabilities/limitations would adversely affect the application
 behavior (or user experience, whatever language is more appropriate
 for the spec) if form redirects were attempted.
 I agree with John on the basis that not all HTTP clients will  
 have JS
 functionality, whether disabled or unavailable, and whether we can
 imagine what those clients would be or not (blackberry, mobile  
 phone,
 iPod, Nike running shoe, car keys). The choice to deprecate HTTP
 redirects involves some assumptions that seem too broad:

 1) Payloads will be  2K often enough that there is little value in
 supporting more than one way to redirect

 Supporting payloads larger then 2K is a requirement.

 I guess I don't understand what this 2K limit is (and this is not
 mentioned in the spec) - are you talking about limits on the URL size
 when doing an HTTP GET?

yes

 If so, why not use POST instead?

Now I am really confused about what you are talking about


 I foresee this to
 be fairly common in the future as digitally signed claims get  
 moved around.

 2) JS will be available to automate the user experience, or at least
 that automating the user experience isn't that important.

 JS is widely available now, and if not, the user needs to click a
 button, so things still work. In an AJAX world, this is pretty much a
 given now.

 As you note below, JS/AJAX-capable browsers may be present on high-end
 phones, but there aren't many of those in comparison to lower-end  
 phones.


 3) Deprecating functionality already built into the key spec (HTTP),
 that is already in use in OpenID 1.x, is preferred to supporting it,
 even though form redirects will involve more moving parts and specs
 (ECMA / JS) to maintain the same basic user experience.

 Moving to one way to do things instead of two is desirable. If POST
 turns out to be a real issue in the real world, then we can revisit.
 Libraries are supporting both.

 It also allows a good separation from URL parameters private to  
 the RP
 and request parameters intended for the OP.


 What do you think?

 How would you suggest the servers determine wether to use GET or  
 POST?

 Can't YADIS be used to obtain such metadata from the IdP?

That does not make any sense. You are stating that the user agent  
might not be able to support JS. Not supporting JS would mean the  
RP / OP would need to figure out what the user agent supported so  
that it could decide on using GET or POST.

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


Re: IdP's Advertising Both http and https

2006-11-12 Thread Dick Hardt

On 9-Nov-06, at 7:45 AM, Rowan Kerr wrote:

 On Wed, 2006-11-08 at 00:42 -0800, Dick Hardt wrote:
 -Original Message-
 From: Recordon, David

 But the security warnings will still exist:
  - RP redirects me to http on IdP
  - IdP redirects me to https on IdP for login page (warning)

 no warning on GET redirects

 If GET is going to be an acceptable method for responses, the spec
 should be updated. Section 5.2.1. HTTP Redirect states:

   This method is deprecated as of OpenID Authentication version
   2.0 though is still required for implementation to aide in
   backwards compatibility.

To clarify, the GET redirect that I am referring to is one to is to  
the same host.

We moved to a POST between RP and OP so that we could move more data.

-- Dick

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


Re: OpenID Auth 2.0 and user-agent neutrality (or, OpenID with REST/SOAP)

2006-11-12 Thread Dick Hardt
Hi Adam

The switch from GET to POST was made so that we were not constrained  
by the URL parameter payload limit.

As you point out, HTTP headers can be used for moving messages as  
well, but there was no clear mechanism to do that without modifying  
all the widely available browsers.

I think REST support is a really useful feature, and have described  
how that might happen in the past, but right now we are pretty  
focussed on getting browser based auth finalized, and I think the  
mechanisms for rich clients will be related, but slightly different.

-- Dick

On 12-Nov-06, at 5:24 PM, Adam Nelson wrote:

 I've been tracking OpenID auth from 1.0 with great interest.  Last
 summer Johannes Ernst explained to me how it was that one might use
 openid to authenticate a non-interactive user agent such as a REST API
 consumer by intercepting the RP's redirect and providing the info from
 the IdP itself.  Given OpenID's design goals (decentralized,
 lightweight, flexible identity management), and its seemingly
 inevitable adoption into the mashup-minded web 2.0 ecosystem (God help
 me I'm buzzwording!), it seems to me that OpenID's value is
 significantly enhanced if the identities it enables can be used to
 authenticate to SOAP and REST APIs as well as interactive web sites.

 Having said that, I was surprised to note in draft 10 of OpenID Auth
 2.0 that the HTTP redirect method of communication between the RP and
 the IdP is deprecated in favor of an HTML forms-based approach.  This
 suggests to me that OpenID Auth 2.0 is not compatible with REST or
 SOAP or any other binding that doesn't involve the exchange, parsing,
 and submission of HTML forms.

 I'm curious why this decision was made, and if its implications have
 been fully considered.  Has there been any thought given to an
 alternative means of authentication, perhaps via custom HTTP headers
 or some other non-HTML means?  If not, does this mean OpenID is not
 intended to support authentication to programmatic APIs?

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



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


  1   2   >