Re: Requiring Pseudonymous Identifier

[Dick Hardt]

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


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


would you elaborate on the group identifier concept?




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

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

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


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

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

[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

[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

RE: Suggested scoping for AX 2.0 WG

[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 
mailto: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.com<http://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

Suggested scoping for AX 2.0 WG

[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: Request for consideration of AX 2.0 Working Group Charter Proposal

[Dick Hardt]

+1 to a separate WG to fix SREG. Adding language to SREG 1.1  
recommending AX for new development would clarify for the community  
the direction. (I'm presuming there is consensus on one spec long term  
and that the extensibility of AX is preferred)


-- Dick

On 27-Jan-09, at 6:30 PM, Allen Tom wrote:

I agree with Martin. I believe that AX is the correct solution in  
the long run, but given that there appears to be more SREG  
implementations currently in the wild, we should update it to make  
it useful for sites that want to use it.


The other factor is that our lawyers feel very strongly that the  
user should have the opportunity to read the RP's privacy policy  
before authorizing any data exchange, and only SREG has the ability  
to do this automatically. The alternative would be to use OAuth, and  
require RPs to pre-register with Yahoo and provide their privacy  
policy and/or agree to a ToS before using our OP.


Allen

Martin Atkins wrote:


I agree that having both is not ideal, but I also feel strongly  
that we need to have a good SREG 1.1 spec because in practice today  
there are lots of SREG implementations and it is important to be  
able to interoperate with them even if in the long term we'd like  
to move to AX.


This is, incidentally, why I was previously proposing forming an  
SREG group whose task is *only* to fix the spec to reflect current  
practice. This should encourage SREG interop in the short term  
while new developments to AX will encourage a move to AX in the  
longer term.



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


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

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

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


___
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: Request for consideration of AX 2.0 Working Group Charter Proposal

[Dick Hardt]

Hey Everyone
I dropped off the planet for a bit moving and getting my world setup. Have
missed all the email threads on this.

What have I missed out on? :-)

I plan on participating heavy in the AX 2.0 spec myself.

-- Dick

On Tue, Dec 23, 2008 at 12:12 PM, Allen Tom  wrote:

> I believe that one of the goals of AX 2.0 should be to maintain
> backwards compatible with AX 1.0 whenever possible.
>
> Allen
>
>
> Mike Jones wrote:
> > Can you add a clear statement to the draft charter that implementations
> already using AX 1.0 will remain compatible with the output of this working
> group?  Or is backwards-compatibility with existing AX implementations not a
> goal of this work?
> >
> > -- Mike
> >
> > -Original Message-
> > From: specs-boun...@openid.net [mailto:specs-boun...@openid.net] On
> Behalf Of Breno de Medeiros
> > Sent: Thursday, December 18, 2008 6:18 PM
> > To: OpenID Specs Mailing List
> > Cc: d...@skip.com; hd...@ic-tact.co.jp; mgra...@janrain.com
> > Subject: Request for consideration of Working Group Charter Proposal
> >
> > I would like to submit the following proposal for a new Working Group
> > charter to your consideration, following the OpenID IPR process:
> >
> > The proposal charter is also available at:
> > http://wiki.openid.net/Working_Groups:AX_2.0
> >
> > OpenID Attribute Exchange 2.0 Working Group (AX 2.0)
> >
> >
> > Charter Proposal
> >
> > In accordance with the OpenID Foundation IPR policies and procedures
> > this note proposes the formation of a new working group chartered to
> > produce an OpenID specification. As per Section 4.1 of the Policies,
> > the proposed charter is below (still liable to change during this
> > feedback period).
> >
> >
> > I. Name
> >
> > Attribute Exchange Extension Working Group (AX)
> >
> >
> > II. Statement of Purpose
> >
> > Produce an updated version of the Attribute Exchange Extension.
> >
> >
> > III. Scope
> >
> > Update the Attribute Exchange Extension to include support for
> > identified needs. Currently identified needs:
> >
> > * Provide mechanisms for RP to require, and the OP to assert,
> > claims about the quality of the attributes.
> > * Create an extensible registry of claim types, such as
> > axschema.org for attribute types. The registry should also provide
> > non-normative guidance on how claims can be validated, which will
> > depend on the nature of attribute type as well as claim type.
> > * Introduce a new request/response mode which, unlike fetch and
> > store, allows for both transmittal of some values and request of
> > others. The transmittal not necessarily has the significance of a
> > "store" request (could be informative, or for requesting validation).
> > * Introduce a direct communication method in both directions
> > (OP<->RP), supported via discovery, for bulk exchange of attributes
> > about (potentially) multiple users.
> >
> >
> > IV. Specifications
> >
> > OpenID Attribute Exchange 2.0
> >
> >
> > V. Anticipated audience
> >
> > All those interested in the obtaining attributes about users
> > authenticated via OpenID.
> >
> >
> > VI. Language of business
> >
> > English.
> >
> >
> > VII. Method of work
> >
> > Mailing list discussion. Posting of intermediate drafts in the OpenID
> > Wiki. Virtual conferencing on an ad-hoc basis.
> >
> >
> > VIII. Basis for completion of the activity
> >
> > The Attribute Exchange 2.0 spec final draft is delivered and the form
> > of management and maintenance of the registry is established.
> >
> >
> > Background Information
> > I. Related Work
> >
> > Attribute Exchange (1.0), and Simple Registration.
> > II. Initial Membership
> >
> > * Tom Allen, a...@yahoo-inc.com. Yahoo! Inc (editor)
> > * Mike Graves, mgra...@janrain.com, JanRain, Inc.
> > * Dick Hardt, d...@skip.com. Sxip Identity.
> > * Breno de Medeiros, br...@google.com. Google, Inc. (editor)
> > * Hideki Nara, hd...@ic-tact.co.jp, Tact Communications
> > * Nat Sakimura, n-sakim...@nri.co.jp (editor)
> >
> >
> >
> >
> > --
> > --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
> >
>
> ___
> 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: What is the status of AX 2.0 WG proposal?

[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 :
>> 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: Could you update me of the status of CX WG proposal?

[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?

[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: Use of Qworum for indirect communication

[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:



  checkid_setup
  ...


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



2008/12/16 David Fuelling 
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 
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:





  
  



  checkid_setup
  http://openid-provider.net/my_idopenid:identity>

  ...


  



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:



  checkid_setup
  http://openid-provider.net/my_id
  ...


3. The OP interacts with the end user.

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



  id_res
  http://openid-provider.net/my_id
  ...


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

___
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

[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

[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

[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 PR

Re: Proposing an OpenID Authentication 2.1 Working Group

[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

[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?

[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
> .
> ___
> 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 board] The Specifications Council

[Dick Hardt]

Fabulous!

On 3-Jun-08, at 11:20 AM, David Recordon wrote:

> The past editors of OpenID Authentication 2.0 (Josh Hoyt, Johnny Bufu,
> and myself) just got off a phone call where we elected the remaining
> five individuals to the specification council.  As everyone knows, the
> council is designed to both create a separation between the board of
> the OIDF and the community technical working groups and to provide
> guidance as future OpenID specifications are being developed.  We've
> thus unanimously elected the following individuals to the council to
> serve the initial term joined by Dick Hardt and Mike Jones from the
> OIDF board:
>
>  - Allen Tom
>  - Brad Fitzpatrick
>  - David Recordon
>  - Johnny Bufu
>  - Josh Hoyt
>
> ___
> board mailing list
> [EMAIL PROTECTED]
> http://openid.net/mailman/listinfo/board
>
>

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

RECOMMENDED: Proposal to create the PAPE working group

[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: Correct AX Namespaces

[Dick Hardt]

On 1-May-08, at 9:16 AM, John Ehn wrote:


OpenID Colleagues,

I (and a few other people) are rather confused about the current  
state of Attribute Exchange, and the default namespace URIs.  Which  
of the following will be the correct namespace root for the future?


http://schema.openid.net/
http://openid.net/schema/
http://axschema.org/

- MyOpenID supports http://schema.openid.net/

- The "Attribute Properties for OpenID Attribute Exchange" spec at http://openid.net/specs 
 calls out http://openid.net/schema/.  I don't know if there are any  
OPs that implement this version.


That is a boo-boo. I thought it had been fixed to NOT refer to a  
namespace.




- axschema.org calls out http://axschema.org/


That is the namespace that we concluded to use on the list on the  
past. If people want, we can open up the discussion again. I agree the  
community needs to be clear on the namespace.


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

Re: OpenID and Yahoo

[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

[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: Using email address as OpenID identifier

[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: Using email address as OpenID identifier

[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 doe

Re: Using email address as OpenID identifier

[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: [security] Phishing-Resistant Authentication definition

[Dick Hardt]

On 20-Nov-07, at 1:40 PM, David Recordon wrote:

> Do you have proposed wording for this?

not right now :-)

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

Agreed that it will make it easier to get agreement. Not sure "No  
Shared Secret" is the right one though. Being Phishing Resistant was  
the driver for the policy though and the reason why people care.

Alternatively, we could change the protocol so that it is Phishing  
Resistant without having to have an extension! :-)

-- Dick

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

Re: RP generated nonce for stateful mode.

[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

Phishing-Resistant Authentication definition

[Dick Hardt]

Recently this definition of Phishing-Resistant Authentication was  
proposed:




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


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


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

Re: OpenID 2.0 finalization progress

[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

[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

[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 2.0 finalization progress

[Dick Hardt]

+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

Re: OpenID Attribute Exchange Protocol questions

[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: OpenID Attribute Exchange Protocol questions

[Dick Hardt]

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

Agreed.

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

Re: OpenID Attribute Exchange Protocol questions

[Dick Hardt]

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

> [replying to myself]
>
> On 10/07/07, James Henstridge <[EMAIL PROTECTED]> wrote:
>> The only real constraint the authentication spec places on the RP is
>> that it maintain the association for the duration of an OpenID
>> authentication request.
>>
>> With unsolicited response though, there is no prior request that  
>> tells
>> us the RP is holding a particular association _right now_.
>
> I just realised another difference when working with unsolicited  
> responses.
>
> With a normal OpenID authentication request the RP picks an
> association handle, so we know the RP believes it is valid.  However,
> the OP can use a private association handle in the response if it
> considers the handle from the request to be invalid.  So the OpenID
> authentication spec does not seem to require either the RP or OP to
> store an association for longer than ~ one request.
>
> In contrast, if a previously established association is used in an
> unsolicited response there doesn't seem to be any way the RP can tell
> the OP that it has lost the handle.
>
> 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.

-- Dick



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

Re: OpenID Attribute Exchange Protocol questions

[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

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

[Dick Hardt]

On 11-Jun-07, at 1:45 PM, Josh Hoyt wrote:
>
> If I understand Dick, he's proposing using multiple identifiers as a
> kind of multi-factor authentication, where the user has to present
> more than one credential in the form of identifiers to take an action.
> This is very similar to your interpretation of two URLs being
> necessary. It's an interesting idea, and it has a lot of nice
> properties, but it seems like a pretty big leap at this point. I think
> the biggest drawback is that the nice properties only really appear
> when each identifier is issued by a separate authority.

The multiple identifiers resolves problem B of losing control of an  
identifier, and would also enable identifier recycling.

If you pull back and look at current mechanisms, many of them are  
multiple identifiers. If you forget your password, equivalent to  
losing control of an identifier, you can get a new one sent to your  
email address and you can change your password (identifier). If you  
don't have access to your email anymore, some sites ask you a number  
of "secret" questions, and if you have that information, then it is  
another "identifier".

Just to clarify, I do *not* propose we add support for multiple  
identifiers in OpenID 2.0 -- but hope that this discussion sheds  
light that there are other ways of solving the problem besides having  
a permanent directory of identifiers aka the i-names/i-numbers  
mechanisms.

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

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

[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?

[Dick Hardt]

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

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

[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?

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

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

[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.
>  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: No New DB Field Requirement? (WAS: RE: Questions about IIW Identifier Recycling Table)

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

[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: Attribute Exchange external reference?

[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

[Dick Hardt]

On 3-Jun-07, at 10:46 AM, Recordon, David wrote:

> I thought at IIW we agreed that if we could come to quick consensus  
> on a
> way to resolve the problem it would be a part of 2.0, otherwise it  
> would
> not...

That is what we agreed to in Josh's meeting. Then we had a meeting  
the next day and we had consensus from a pretty good sized group that  
included ALL the spec authors.

>
> As concerns with the fragment proposal have been raised, which had the
> most agreement at IIW, it seems we no longer have consensus.  As  
> seen in
> this thread, there are a wide variety of opinions as to how to resolve
> this concern.  I thus think merely picking one for the sake of putting
> something into 2.0 would be misguided.

I'm not clear what the issues with the fragment are. Josh's issue  
does not make sense as the user does not really know they have a  
fragment in their identifier.

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

Re: Specifying identifier recycling

[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 (x>1) 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: Specifying identifier recycling

[Dick Hardt]

A little late to the conversation, but some comments inserted as I  
did not see them all in any other aspect of this thread ...

On 30-May-07, at 10:28 PM, Josh Hoyt wrote:

> Hello,
>
> I started writing up the use of fragment identifiers for URL-recycling
> for the OpenID 2.0 authentication spec, and I ran into some unforseen
> challenges. It's not obvious how a relying party should behave when a
> URL with a fragment is entered. How should the discovery process work?

The user does not use the fragment. If they do type it in, the RP can  
strip it.

> How should fragments work with delegation (both as the claimed
> identifier and the provider-local identifier)?

Not sure there is an issue here. Can you elaborate?

>
> After thinking this over for a while, I'm no longer convinced that
> using URI fragments as the uniquifying value is the right
> approach. Looking at the available options, I think that the best
> approach might be to add a uniquifying value to some part of the URL,
> in a provider-specific manner. For instance:
>
>   I own . I delete my account, and so it
>   goes back in the pool of identifers. The next Josh who registers the
>   username "josh" at MyOpenID.com gets .
>
> Providers can also provide a redirect from the general form of the
> identifier to the current version of the identifier so that users do
> not need to remember or type the uniquified version. This is pretty
> much equivalent to the fragment scheme, except:
>
>   * It does not require spec changes (and is backwards-compatible!)
>
>   * The uniquifying component is user-visible

the user now has to enter something that is not as memorable -- there  
is little difference between http://josh.myopenid.com/1 and http:// 
josh1.myopenid.com/

Your approach does not solve the recycling problem.

>
> I'd like to hear opinions on whether this unique-URL solution is good
> enough to solve the problem. If you think it isn't, I'd like
> suggestions on how discovery and delegation should interact with
> fragments.
>
> Josh
>
>
> For reference, here's a comparison of the three different approaches
> to solving the identifier recycling problem:
>
> 1. Using a URI fragment with a uniquifying value:
>
>   * No database changes necessary on the RP (the RP can store the URL
> with the fragment as the identifier)
>
>   * Potential problems with initiation and discovery

The user types in the memorable part of the URI, and not the fragment.

>
>   * Potential problems with inconsistent behaviours on OpenID 1 sites

We discussed this at IIW and the consensus was that we would just  
have to get them to upgrade. Many of them will not allow the user to  
enter an i-name or OP currently anyway.

>
>   * Comparing identifiers is easy
>
>   * URLs that user see may be ugly or inconsistent across sites (if
> some relying parties do and others do not strip the fragment
> before display)
>
>   * There is no difference between different versions of a
> *user-displayed* identifier (users can't tell if a reference to a
> URL in the wild belongs to the current ownder of a URL or another
> user).
>
>
> 2. Adding an extra field with a uniquifying value:
>
>   * Database change required
>
>   * No change in initiation or discovery
>
>   * OpenID 1 sites will behave as they do now
>
>   * Identifier comparison is no longer obvious
>
>   * Display URLs are easy
>
>   * There is no difference between different versions of an identifier

ISSUE: The new user of the identifier will get access to the old  
user's account.

>
>
> 3. Just use different URLs:
>
>   * No database change required
>
>   * No change in initiation or discovery
>
>   * No implementation change at all (just a new best practice)
>
>   * Comparing identifiers is easy
>
>   * Display URLs are easy
>
>   * Users can tell the difference between an old and a new identifier


ISSUE: URIs are not being recycled


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

Re: Final outstanding issues with the OpenID 2.0 Authenticationspecification

[Dick Hardt]

On 17-May-07, at 10:57 PM, Alaric Dailey wrote:

> I hate to be a PITA but these issues were brought up a while ago by  
> Eddy
> Nigg and Myself.
>
>
>
>
>
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of  
> Josh Hoyt
> Sent: Thursday, May 17, 2007 15:50
> To: Alaric Dailey
> Cc: OpenID specs list
> Subject: Re: Final outstanding issues with the OpenID 2.0
> Authenticationspecification
>
> On 5/17/07, Alaric Dailey <[EMAIL PROTECTED]> wrote:
>>  There are 2 issues that I would like to see addressed.
>>
>> 1. Forcing Encryption, to protect users data en-route.

This could be an extension. Enabling Encryption is an option. Hard  
sell to force encryption.

>> 2. Validated assertions, validating certain bits of data with a third
> party.
>>
>> I know both of these have come up before, but have met with
>> resistence, I would submit that with Sun and AOL supporting OpenID
>> that these issues become more important, especially protecting the  
>> users
> data.

We have done this type of stuff with Attribute Exchange.





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

Re: correlating an OpenID value being stored to the OP attribute that should hold it

[Dick Hardt]

Hi Mark

Let me restate your concern so that I'm sure I understand it:

RP requests the axschemas.org/schema#SingleValuedSaluation attribute  
from OP

The OP has the following attributes available:
foo.com/schema#ProfessionalSalutation
foo.com/schema#InformalSalutation

I'm asumming that the meta-data from both:

foo.com/schema#ProfessionalSalutation
foo.com/schema#InformalSalutation

state they are equivalent to

axschemas.org/schema#SingleValuedSaluation

The user then selects which one they want to return to the RP, or the  
user could even enter a different value.

The OP would then store this attribute as

axschemas.org/schema#SingleValuedSaluation

for later retreival since it has learned what value the user would  
like to use in this case

If later on the RP interacts with the user and there is a new value,  
then the OP would store it as an additional value that could be  
returned for

axschemas.org/schema#SingleValuedSaluation

The OP could keep the old value for

axschemas.org/schema#SingleValuedSaluation

around in case the user wants to use it again.

-- Dick

On 16-May-07, at 9:03 PM, Mark Wahl wrote:

>
> In the discussion of schema at the IIW2007 there was a
> scenario in which an RP asks for an attribute of an OpenID identity
> provider, but that provider doesn't hold that specific attribute,
> only one or more related attributes.
>
> For example, the suppose RP fetches for an attribute whose URI is
> axschemas.org/schema#SingleValuedSaluation
>
> and the OP holds two attributes
> foo.com/schema#ProfessionalSalutation
>   Dr. Smith
>   John Smith, MD
>
> foo.com/schema#InformalSalutation
>   John
>
> Then the OP prompts the user to select which one to return in the
> fetch response
>   Dr. Smith (Professional)
>   John Smith, MD (Professional)
>   John (Informal)
>   (none)
>
> If the OP returns only that #SingleValueSalutation has the value
> chosen by the user, e,g. "John Smith, MD", then the knowledge that
> this value comes from the #ProfessionalSalutation attribute is lost.
> If the RP only is interested in querying this information, then
> this lost knowledge isn't a problem for the OP, however it is a
> problem if the RP subsequently performs a AX store operation back to
> the OP to update this information.
>
> Later, if the RP performs a store to update the
> axschemas.org/schema/#SingleValuedSalutation, the semantics of
> the attribute is that it is single-valued, so the new value should
> replace an existing value.  However, since the OP doesn't hold that
> attribute, it needs to be able to determine which attribute
> (#ProfessionalSaluatation or #InformalSalutation) the store refers to.
> It is desirable that the OP be able to 'tunnel' the information
> of which actual attribute this is replacing through the RP, even if  
> the
> RP doesn't recognize the distinction between the forms of salutation,
> so the OP can know which attribute the RP is referring to.
>
> This issue could be addressed by a parameter in the OpenID attribute
> exchange included in the fetch response and store request.   Both of
> these are optional.
>
> For example,
>
> Fetch Response Format
>
> openid.ax.origin..
>
>   Identifies the origin attribute of the value referred to
>   by the  and .  This parameter is returned if
>   the fetch request indicated a generic attribute, and
>   the OpenID provider did not hold that generic attribute,
>   so the OpenID provider is returning a value of a more
>   specific attribute.  The format of this parameter is a URI.
>
> Store Request Format
>
> openid.ax.origin..
>
>   Identifies the origin for the value referred to by the
>and .  This URI is provided by the RP if
>   the RP is updating an existing value, and the value being
>   updated was accompanied by an
>   openid.ax.origin.. in an earlier fetch
>   response.
>
>
> 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

Re: Enterprise Concerns

[Dick Hardt]

On 29-May-07, at 11:20 PM, Johannes Ernst wrote:

> Amen. Great list.
>
> I would add one more: let's focus single-mindedly on things that we  
> actually know are demanded by the market without which adoption  
> does not occur, instead of growing the amount of technology that  
> needs to be implemented into places where ROI (for implementors,  
> deployers, users, ...) is at best uncertain.

That sounds like a good theme Johannes. I have comments using that as  
a metric to James points below:

>
> Okay, I'm exaggerating. But directionally, I don't think I'm wrong  
> -- witness the discussion about the "complexity" of Authentication  
> 2.0 and the perceived relative benefits.
>
>
> On May 29, 2007, at 13:33, McGovern, James F ((HTSC, IT)) wrote:
>
>> Been silently observing many of the email exchanges over the last  
>> couple of weeks and from an end-customer perspective I am somewhat  
>> concerned. Some of the general themes I have observed are:
>>
>> 1. Too much focus on breaking compatibility with OpenID 1.1. While  
>> you have had some success, now is the time to break things. It is  
>> more important to get to the right long term approach earlier in  
>> the lifecycle.

I would agree with this.

>>
>> 2. Too much focus on being unphishable. While this is important  
>> and foward progress should happen, I don't think that this should  
>> be the only focus. I salute Kim Cameron for getting folks off  
>> their butt to solve this problem though.

Being easily phishable is stated barrier to adoption by most major  
portals. It needs to be solved.

>>
>> 3. Publish, publish, publish. Stop iterating and start publishing.  
>> The draft is way overdue and folks will not pay attention to a  
>> specification where velocity of change is occuring this frequently.
>>
>> 4. Tackle and discuss issues head on. I have seen several valid  
>> issues where folks way too easily dismissed the concern stating  
>> cliche phrases such as not in scope, someone else's problem, etc.

Sometimes things are out of scope. More often then not, a proposal is  
put out there and there is radio silence

>>
>> 5. Not soliciting end user feedback. The observation is that there  
>> are lots of folks attempting to create a product around the spec  
>> and are simply iterating in order to be interoperable but haven't  
>> asked themselves is this what buyers of software actually desire.  
>> Many of the features that make this interesting seem to go ignored  
>> (e.g. attestation, authorization, support for XACML, etc)

Not sure what you mean by end user feedback. The implementors? We  
have been getting lots of feedback on that.

Agreed that many of the interesting features that are available with  
attribute exchange tend to get ignored now.

At IIW Josh had a meeting to isolate what was still needing to be  
done to release 2.0. I hope we can keep up the momentum that we built  
there and get this version wrapped up!

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

Re: Specifying identifier recycling

[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 (x>1) 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: Persistent Identifiers (was: Proposal for Recycling Identifiers in OpenID 2.0)

[Dick Hardt]

On 28-May-07, at 9:49 AM, Johannes Ernst wrote:

> On May 28, 2007, at 7:20, Claus Färber wrote:
>> Dmitry Shechtman schrieb:
>>> This is definitely an interesting proposal. However, it only
>>> attempts to
>>> solve the recycling problem, whereas canonical IDs would solve
>>> this and
>>> several more.
>>
>> I think the best solution would be a Persistent Identifier. If the
>> OpenID Provider returns a different Persistent Identifier, the  
>> Relying
>> Party can assume the ID has been recycled.
>
> And the best persistent identifier is a public key, because it's
> rather hard to fake. (if there is also an operation that challenges
> the publisher of the public key to use it.)
>
> Which is why we've had GPG key pairs for a long time in LID ...

Public Keys are great until the private key has been compromised.

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

Re: Proposal: ClaimOP -- what does it buy?

[Dick Hardt]

If we work with the assumption that we can add code to the browser,  
then why not let the user configure the browser with their OP(s)?

That puts the browser in the position of sending the user to the OP  
rather then the RP.

-- Dick

On 15-May-07, at 8:43 AM, Boris Erdmann wrote:

> This post continues "Proposal: ClaimOP -- an in-band OP identity
> system" and "Proposition: possible anti-phishing solution".
>
> So what does ClaimOP provide?
>
> It provides browsers with
>
> a) a sure way to detect an OPs looping-in login (LIL) page
> b) sure access to the credential data of a LIL page
> c) enough information to validate an OP's compliance to ClaimOP.
>
>
> What do we get from that?
>
> By means of discovery/YADIS the openid identifier (and as such the
> credential data) carry in-band information about where the credentials
> are allowed to go to. Browsers can easily check the realms of
>
> * the LIL page
> * the form action attribute
> * the discovered openid.server / openid.provider
> (* a yet to be discussed "openid.cred_destination" as part of
> discovery -- if we like that)
>
> to match certain criteria. In consequence a user could never post a
> password to a destination that is not authorized for a specific
> OpenID.
>
>
> Are there issues?
>
> As can easily be seen, ClaimOP shifts a phisher's task from faking
> (RP, OP) to faking identifiers: A malicious OP could fully comply to
> ClaimOP -- but to trick a user into delivering a certain identifier's
> password it has to provide an openid.identifier that
>
> a) is under the realm of the malicious OP
> b) looks similar enough to the users original openid
>
> So a browser has to provide methods to make such fakes visible to
> users. But I think that this is solvable task, since it shifts a users
> focus to a well known and often verified string of characters. Two
> things come to mind:
>
> a) Browsers could always display some kind of "visual hash" next to an
> identifier -- easy to remember and identify. Users would easily
> recognize a change of that. (That needs to be specified)
> b) Browsers could remember OpenIDs. Each first time a new openid has
> to be verified by letting a user retype their id. Faked ids would be
> instantly detected.
>
> -- Boris
> ___
> 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

[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

Re: Proposal for Recycling Identifiers in OpenID 2.0

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

Proposal for Recycling Identifiers in OpenID 2.0

[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

axschema.org instead of openid.net

[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: encoding newlines in attribute values

[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

Re: Java RP

[Dick Hardt]

The OpenID4Java library is licensed under Apache 2.0 -- a very  
commercial friendly license

source development here:
http://code.google.com/p/openid4java/source

package here:
http://code.sxip.com/openid4java/

-- Dick

On 11-Apr-07, at 6:37 AM, McGovern, James F ((HTSC, IT)) wrote:

> I have been thinking that the best contribution I could make to  
> OpenID would be the first enterprise that deploys OpenID into  
> production. OpenID needs more press than it is receiving and by  
> showing that a large Fortune enterprise is using would be a big  
> win. I do however have one constraint in that the absolute fastest  
> way of accomplishing deployment would be for me to identify a 100%  
> unrestricted open source Java RP code base that I could incorporate.
>
> The notion of going through any form of procurement would not allow  
> me to accomplish this goal. Is anyone aware of the existence of a  
> 100% unrestricted open source Java RP code base?
>
>
> ** 
> ***
> This communication, including attachments, is
> for the exclusive use of addressee and may contain proprietary,
> confidential and/or privileged information.  If you are not the  
> intended
> recipient, any use, copying, disclosure, dissemination or  
> distribution is
> strictly prohibited.  If you are not the intended recipient, please  
> notify
> the sender immediately by return e-mail, delete this communication and
> destroy all copies.
> ** 
> ***
>
> ___
> specs mailing list
> specs@openid.net
> http://openid.net/mailman/listinfo/specs
>
>

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

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

[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 

Re: [dev-monkey] Newlines in bio attribute

[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

[Dick Hardt]

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

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

[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: [openid4java] OpenID Attribute Exchange

[Dick Hardt]

Hi Shihab

There is currently a bit of a road block on being able to publish a  
schema for AX so that people can actually use it.

The one OP that does support AX today is Sxipper.

-- Dick

On 9-Apr-07, at 11:38 PM, Shihab wrote:

>
> Hi,
>
> I was wondering if anyone knows of any OpenID Providers which support
> the Attribute Exchange protocol. I'm trying to test the OpenID
> consumer code in OpenID4Java and want to test it with something other
> than itself.
>
> I've tried: myopenid, lid, pip (verisign), videntity and getopenid.
> None of them seem to support the attribute exchange. I'm wondering if
> this is a problem with the OpenID4Java library (ie. should I be
> digging around here) or is this just a general lack of implementation
> of this protocol on the web?
>
> I've been testing attribute exchange online using the Sxip demo:
> https://verify.sxip.com/demorp/ and with the current OpenID4Java
> library.
>
> Cheers,
>
> -Shihab
>
>
> --~--~-~--~~~---~--~~
> You received this message because you are subscribed to the Google  
> Groups "OpenID4Java" group.
> To post to this group, send email to [EMAIL PROTECTED]
> To unsubscribe from this group, send email to openid4java- 
> [EMAIL PROTECTED]
> For more options, visit this group at http://groups.google.com/ 
> group/openid4java?hl=en
> -~--~~~~--~~--~--~---
>
>

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

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

[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: PROPOSAL schema.openid.net for AX (and other extensions)

[Dick Hardt]

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

[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: some questions on OpenID AX 1.0 draft 4

[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." 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.
> parameter specifies the type identifier URI for the attribute referred
> to as . 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. assigns a value  
> to the
> attribute referred to as ."
>
> Is an OP receiving a store response required to save the alias  
> provided by the
> RP for any purpose, or

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

[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 

Re: Promoting OpenID

[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: Web Access Management

[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: PROPOSAL schema.openid.net for AX (and other extensions)

[Dick Hardt]

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

> You also could go buy idschemas.org and start there, to be migrated
> later if need be.  I don't really care who owns the domain since the
> wider community will hold the owner to do the right thing, though I'd
> imagine donating it to Identity Commons to hold would be an easy thing
> to do.

I still see no reason to not start using openid.net for the OpenID  
Community to start working with.

>
> Yes, VeriSign is activly developing OpenID 2.0 code in Java
> (http://code.google.com/p/joid/) and evaluating if/when we'll be
> implementing Attribute Exchange alongside Simple Registration.

I'd welcome feedback, suggestions and contributions from VeriSign  
individuals if/when they work with Attribute Exchange!

btw: for someone that preaches not reinventing the wheel, why is  
VeriSign working on a new Java implementation instead of working with  
one of the existing ones like OpenID4Java?

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

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

[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.c

Re: Attribute Exchange 1.0 svn revision 295 review

[Dick Hardt]

On 5-Apr-07, at 4:48 PM, Josh Hoyt wrote:

> On Apr 5, 2007 at 8:41 AM, Dick Hardt <[EMAIL PROTECTED]> wrote:
>> > 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.
>
> Generally, yes, although when we were discussing the spec, we talked
> about using one pass of attribute exchange to get all of the available
> attributes and another pass to request the attributes themselves. When
> requesting the available attributes, it seems like you'd want to say
> "give me all the attributes that are available" instead of "give me up
> to 500 available attributes," but I could be wrong.
>
> It might be good to give a bound on the response size for every
> request, although in cases such as above, it might be useful to the
> relying party to know if there were values that overflowed the limit.
> It wouldn't be difficult to add a flag, but I'm also not sure whether
> it would be worth the extra complexity.

Our experience to date has been that we don't have multiple so far. I  
am sure there will be some use cases that do.

Good question if those will be limited or not. Our thinking had been  
that some applications may have 4 slots for attributes in the DB, so  
only would ask for up to 4 attributes.


>
>
>
>> > 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
>
> Well, clearly it's better to have one way to do it. But seriously, the
> main problem that I have with it is that the specification prescribes
> the response format based on the request format. That is, my code has
> to keep track of whether the request used count=1 or just didn't
> specify a count, instead of just recording that the request asked for
> one value, so that the later code can know how to encode the value. If
> there's really more than one way to do it, you should be allowed to do
> it either way.

I agreed with you previously that the response being able to work  
either way if the request can. Sorry if that was not clear.

>
> I'm guessing that you made that restriction on the response format so
> that relying parties can know what the form of the response will be.
> Is that correct?

It was on the grounds that this is what the RP had requested, so the  
OP should do the same. But I agree with you that allowing either is  
preferred, and am also ok with there only being one way of asking for  
a single value. No strong opinion here on that.

> Another restriction on the response message is that you have to send
> responses even if they are empty. Can you give the rationale for
> requiring the fields with no values to be sent?

I am unclear on what your question is. Would you clarify?

-- Dick


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

Re: Logout

[Dick Hardt]

The was a discussion was on the user-experience list called single  
sign out

http://openid.net/pipermail/user-experience/2006-November/subject.html

I wrote up a list of issues we had seen at Sxip and our user  
experience testing that indicated it was not a high value feature

-- Dick

On 6-Apr-07, at 12:59 PM, Praveen Alavilli wrote:

> I could only go only till Aug 2006 on the mail archives here:
> http://openid.net/pipermail/specs/ and nothing found specifically on
> "logout' (atleast based on the thread subjects).
>
> Any one know how and where we could get older archives ?
>
> thx
> Praveen
>
> Josh Hoyt wrote:
>> On 4/6/07, Praveen Alavilli <[EMAIL PROTECTED]> wrote:
>>> well with OpenID atleast, I think we can easily design a logout
>>> extension, [...]
>>> Any reason why something like this was not incorporated into the
>>> specs yet ?
>>
>> There is not general agreement on how this feature should be
>> implemented, or even exactly how it should work. Anyone care to  
>> search
>> back through the list archives and dig up the many previous
>> discussions of this topic? It'd be useful to the discussion to gather
>> the previous discussions together and make a wiki page about sign-out
>> with links to the previous discussions and a summary of the issues  
>> and
>> possible solutions to those issues (rather than a proposal).
>>
>> 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: PROPOSAL schema.openid.net for AX (and other extensions)

[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

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

[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: Moving AX Forward (WAS RE: SREG namespace URI rollback)

[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

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

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

[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: Moving AX Forward (WAS RE: SREG namespace URI rollback)

[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: Attribute Exchange 1.0 svn revision 295 review

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

[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: Moving AX Forward (WAS RE: SREG namespace URI rollback)

[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 mec

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

[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: Promoting OpenID

[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: SREG namespace URI rollback

[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: Web Access Management

[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: Server-to-server channel

[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: Server-to-server channel

[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

[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

[Dick Hardt]

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.

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

Re: Attribute Exchange pre-draft 5

[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: Attribute Exchange pre-draft 5

[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: Features for Future Versions

[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