Re: [OIDFSC] Request to consider creation of the User Interface Work Group
+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
To be clear, what I have suggested is not the bulk exchange of multiple users. It is the method to treat number of attributes as a group that requires some integrity within them. When it comes to CX, by design, it does not do multi user exchane either since it requires the parties to explicitly sign the contract. The advantage of keeping it in this WG is that we make sure that different approaches to handling exchange of user attributes are viewed by the same people, even if it ends up in a separate mini-spec. The counter-argument is that most members of this WG are not interested primarily in this functionality, and it may distract both efforts (CX and AX), and that AX is unlikely to directly support anything along these lines. I think that Nat’s description above is a general requirement and makes sense to be in scope. To clarify, bulk movement of attributes from different users is not in scope – grouping attributes together would be in scope (I’m interested in this functionality) Anyone have a concern with that? - Dick ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Suggested scoping for AX 2.0 WG
1) I'd prefer to NOT include SREG in the work, but am ok with it being in if the scope is really to clarify issues in SREG and add language directing people to AX. Anyone else have a strong opinion either way? (SREG included in this WG or in a different one?) 2) In the Scope section, I feel strongly that bulk exchange of attributes about multiple users is out of scope. It is a very different design pattern then what AX does now. I have not seen the background on why this is in scope, so perhaps I can have a different view if someone cares to enlighten me. -- Dick PS: please use my microsoft.com address for any specs discussions. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Suggested scoping for AX 2.0 WG
Thanks for the feedback Breno! Nat: can you provide some illumination? I see that CX would define attribute types to be carried in AX. I'm confused about the scenario where information from multiple users would be transmitted as that implies that the protocol no longer is dealing with a single subject. -Dick From: Breno de Medeiros [mailto:br...@google.com] Sent: Tuesday, February 03, 2009 2:39 PM To: Dick Hardt Cc: da...@sixapart.com; Allen Tom; Martin Atkins; Nat Sakimura; OpenID Specs Mailing List Subject: Re: Suggested scoping for AX 2.0 WG On Tue, Feb 3, 2009 at 2:19 PM, Dick Hardt dick.ha...@microsoft.commailto:dick.ha...@microsoft.com wrote: 1) I'd prefer to NOT include SREG in the work, but am ok with it being in if the scope is really to clarify issues in SREG and add language directing people to AX. Anyone else have a strong opinion either way? (SREG included in this WG or in a different one?) I'm ok either way. 2) In the Scope section, I feel strongly that bulk exchange of attributes about multiple users is out of scope. It is a very different design pattern then what AX does now. I have not seen the background on why this is in scope, so perhaps I can have a different view if someone cares to enlighten me. When Nat Sakimura wrote the contract exchange CX proposal, he included scope for exchanging validation/metadata about attributes, and it was felt that it should belong here. CX also needs this bulk exchange functionality and again because it pertained to attributes, it was believed that it would better fit here. The advantage of keeping it in this WG is that we make sure that different approaches to handling exchange of user attributes are viewed by the same people, even if it ends up in a separate mini-spec. The counter-argument is that most members of this WG are not interested primarily in this functionality, and it may distract both efforts (CX and AX), and that AX is unlikely to directly support anything along these lines. -- Dick PS: please use my microsoft.comhttp://microsoft.com address for any specs discussions. -- --Breno +1 (650) 214-1007 desk +1 (408) 212-0135 (Grand Central) MTV-41-3 : 383-A PST (GMT-8) / PDT(GMT-7) ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Request for consideration of AX 2.0 Working Group Charter Proposal
I'd prefer to narrow the scope of the WG and keep it focussed on a small number of goals. A separate WG on SREG would be preferred, but I think it is a disservice to the community to have two specs having such significant overlap. Choice in this case leads to confusion and reluctance to invest. The challenge is that those with an investment in SREG now have a propensity to see it continue on even though intellectually they can see the advantage of a unified spec. fwiw: I am in an off-site most of this week and won't be able to engage significantly until next week. -- Dick On 26-Jan-09, at 9:34 PM, Breno de Medeiros wrote: Let's please maintain the discussion on this thread on definition of the scope of the WG. Once the WG is formed, the technical aspects can be discussed there. The only pertinent issue that is left open in this regard appears to be whether or not SREG will be inspected as part of this. Allen, please edit the WG proposal charter to include it. On Mon, Jan 26, 2009 at 9:25 PM, Raghu Nallani Chakravartula ra...@producthorizons.com wrote: Futher, the verification information cannot sometimes be expressed in a single type. It may need to be qualified with additional information as regards who verified it, when, how long is the verification valid etc... I am guessing validation data exchange will need to grow into a struct exchange. -Raghu Paul Madsen wrote: FWIW, the separate 'verified' field is the approach the Infocard community took https://informationcard.net/wiki/index.php/Claim_Catalog They also allow the particular verification method used to be listed https://informationcard.net/wiki/index.php/ Claim_Catalog#Verification_Methods One drawback of this method is that all claims sent together get lumped together into a single bucket wrt verification paul Martin Atkins wrote: Henrik Biering wrote: Agree! If the range of SReg attributes is expanded, however, I would suggest to add phone number (incl. quality as suggested for email) and possibly street+city address line(s). That would make it possible to fill in a somewhat larger part of typical registration forms. It might be good to apply the quality thing to all of the fields. One approach might be to add a verified argument that contains a list of names of fields that the OP has verified in some way. However, I think the SREG spec itself needs work done since the 1.1 draft (that was never published) has a bunch of problems. It might be better to do such work in a separate working group; I already have an updated 1.1 draft with some of the problems from the current 1.1 draft fixed that could potentially be used as a basis, though I'll need to dig it out since I'm not sure what I checked it in to. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs -- Paul Madsen e:paulmadsen @ ntt-at.com p:613-482-0432 m:613-282-8647 web:connectid.blogspot.com ConnectID http://feeds.feedburner.com/%7Er/blogspot/gMwy/%7E6/1 ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs -- --Breno +1 (650) 214-1007 desk +1 (408) 212-0135 (Grand Central) MTV-41-3 : 383-A PST (GMT-8) / PDT(GMT-7) ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Use of Qworum for indirect communication
Designing OpenID around a particular product is clearly a non-starter. Enabling smart clients was discussed as part of OpenID 2.1 at IIW. Smart clients can: reduce the phishing risk of malicious RPs improve the user experience by simplifying the flow improve the performance by reducing the number of HTTP calls. We will still need to continue to support dumb browsers and hence browser redirects and form submission. -- Dick On 17-Dec-08, at 7:38 AM, Doğa Armangil wrote: I think that OpenID auth would benefit from Qworum in a broad sense, because Qworum aims to address the needs of a class of services called multi-phase services, which includes OP-type services. Having said that, two concrete benefits immediately come to mind: 1. Simplified OP Currently the OP does two things: (1) it provides core authentication functionality, and (2) it takes care of integrating itself into the calling RP by keeping track of the return address. When Qworum is used, the non-core task (2) is handled by the user agent, and the OP can concentrate on providing only the core functionality. 2. Robust message semantics With Qworum, authentication request and response messages are XML documents. Needless to say, XML is a mature and powerful messaging format. The one benefit of XML that I will mention here is that it allows the use of namespaces for qualifying OpenID request parameters and response fields (instead of the openid. prefix). Example: message xmlns:openid='http://openid.net/' openid:modecheckid_setup/openid:mode ... /message My general impression regarding the OpenID-Qworum link is that it just makes sense. 2008/12/16 David Fuelling sappe...@gmail.com Cool idea, although I wonder what benefit this would bring to OpenID auth? Seems like HTTP redirects and form submits work pretty well today. Would Qworum enable any sort of new features that aren't possible today because we're not using XML between RP/OP/User-agent? Thanks! david 2008/12/15 Doğa Armangil doga.arman...@gmail.com The OpenID Authentication 2.0 specification states in section 5.2 that There are two methods for indirect communication: HTTP redirects and HTML form submission. It is worth noting that a third method might be added to this list: Qworum ( http://www.qworum.com/ ). Qworum is a fairly new technology (a couple of years old) that aims to solve precisely the problem of indirect communication between interactive web services (such as between Relying Parties and OpenID Providers). Qworum mandates that the caller (i.e. RP) and the callee (i.e. OP) communicate through XML documents. Here is one possible authentication scenario involving Qworum: 1. The RP calls the OP by sending the following Qworum message to the user agent: !-- Return to the RP after calling the OP -- qrm:goto href='/auth_complete' xmlns:qrm='http://www.qworum.com/' !-- Call the OP -- qrm:call href='http://openid-provider.net/my_id' !-- Authentication request message -- message xmlns:openid='http://openid.net/' openid:modecheckid_setup/openid:mode openid:identityhttp://openid-provider.net/my_id/ openid:identity ... /message /qrm:call /qrm:goto This message instructs the user agent to call the OP and to send the result back to the RP. 2. The user agent then calls the OP (i.e. http://openid-provider.net/my_id ) by POSTing it the following XML document: message xmlns:openid='http://openid.net/' openid:modecheckid_setup/openid:mode openid:identityhttp://openid-provider.net/my_id/openid:identity ... /message 3. The OP interacts with the end user. 4. The OP sends the following Qworum message to the user agent: !-- Authentication response message -- message xmlns:openid='http://openid.net/' openid:modeid_res/openid:mode openid:identityhttp://openid-provider.net/my_id/openid:identity ... /message 5. Finally, the user agent then POSTs the authentication response message back to the RP. Note that the RP return address is handled by the user agent, not the OP. Adding Qworum as a third communication method would not break existing methods, it would just offer one more choice to RPs: * The RP can check whether the user agent has Qworum capability by inspecting the Accept header of the HTTP request. The RP can then choose to use Qworum. * The OP would understand that the RP is using Qworum to call it if the Content-Type of the HTTP POST request is application/xml. So my question is this: Has Qworum been considered for indirect communication, or could it be considered in the future? (As the lead developer of Qworum, I can affirm that Qworum would do all it can to facilitate this process.) -- Doğa Armangil ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs -- Doğa Armangil
Re: What is the status of AX 2.0 WG proposal?
I've been busy with other things. :-) I had an in person chat with Allen Tom, Eran and Breno about what they were thinking of. There was some discussion on the step2 list. I have a work item to write up the scope so that we can get it started -- but have needed to deal with some time critical tasks before I could start on it -- sorry. -- Dick On 17-Dec-08, at 4:56 PM, Nat Sakimura wrote: I am very interested in it, but have not heard about it for sometime. What is the status right now? -- Nat Sakimura (=nat) http://www.sakimura.org/en/ ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Could you update me of the status of CX WG proposal?
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?
Breno, if you have time to update the proposal per our discussion that would be fabulous! On 17-Dec-08, at 5:07 PM, Breno de Medeiros wrote: We have made significant process in that in-person chat and we need to document this in proposal draft form. I could try and update the proposal for validate request which has tentatively been abandoned in terms of allowing meta-data to describe attributes in fetch/store requests. 2008/12/17 Dick Hardt dick.ha...@gmail.com: I've been busy with other things. :-) I had an in person chat with Allen Tom, Eran and Breno about what they were thinking of. There was some discussion on the step2 list. I have a work item to write up the scope so that we can get it started -- but have needed to deal with some time critical tasks before I could start on it -- sorry. -- Dick On 17-Dec-08, at 4:56 PM, Nat Sakimura wrote: I am very interested in it, but have not heard about it for sometime. What is the status right now? -- Nat Sakimura (=nat) http://www.sakimura.org/en/ ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs -- --Breno +1 (650) 214-1007 desk +1 (408) 212-0135 (Grand Central) MTV-41-3 : 383-A PST (GMT-8) / PDT(GMT-7) ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Completing the SREG 1.1 specification
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
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
A related topic. Wondering what the community thinks of having two specifications for moving around profile data: we have SREG and AX: do we need both? -- Dick On 28-Nov-08, at 2:33 PM, Martin Atkins wrote: Hi all, It recently became apparent that version 1.1 of the Simple Registration Extension (SREG), which updates the protocol to work as an OpenID Authentication 2.0 extension, was never finished and published. Furthermore, it has been noted that the latest draft contains ambiguities about how SREG is to be used in 1.1 vs. 2.0 messages, and that in some cases it does not describe how SREG is used by popular implementations today. I'd like to form a working group to get version 1.1 completed, with a focus on simply writing down what current implementations do to aid interoperability rather than making any changes. I have a draft of a more formal working group proposal prepared, but first I'd like to see who is interested in working on this. The minimum membership for an OpenID Foundation working group is five members. I anticipate that this group's work will be done relatively quickly, since we'd merely be documenting established practice. Please reply here if you'd be interested in joining this working group, and in particular whether you are willing to be listed as a proposer in the working group proposal. I have included below my current draft working group proposal. I welcome any comments on it. Thanks, Martin OpenID Authentication 2.0 was finalized this past December and since has started to see quite reasonable adoption. Many implementations of Authentication 2.0 have made use of the Simple Registration Extension that was popularized as an ad-hoc OpenID 1.1 extension. While SREG is compatible with and has been deployed using the more formal extension mechanism described in OpenID Authentication 2.0, a 2.0-compatible version of SREG was never published. A draft revised version is available [1], but it was never approved as a specification and contains some ambiguities about how SREG is used in 2.0 vs 1.1 messages. This proposal is to form a working group to finish and publish a version of SREG that is compatible with OpenID Authentication 2.0, describing how SREG is used in existing popular implementations. == Background information == Many implementors have extrapolated how SREG 1.0 can be used within the extension mechanism defined in OpenID Authentication 2.0, but this has actually never been documented in a specification. A draft of SREG 1.1 was produced[1], but it was not published and has been found to contain some ambiguities and deviations from established practice. == Working Group Name == OpenID Simple Registration Extension 1.1 == Purpose == To complete and publish the SREG 1.1 specification, documenting how SREG is used by popular implementations today. == Scope == The proposed work is as follows: * Update the SREG specification to describe how it can be used as an OpenID 2.0 extension as well as an OpenID 1.1 ad-hoc extension. * Update the SREG specification to correct any deviations between the specification and established implementation practice. Note that this charter does not include adding new features to Simple Registration; ideally, the specification produced by this working group will merely be documenting existing implementation practice, and will require no changes to existing implementations as far as possible. Where implementations differ, an approach will be chosen on the basis of number of deployments and on consensus within the working group. == Anticipated Contributions == * Feedback from library authors and other implementors about how they have adapted SREG 1.0 to work within OpenID 2.0's extension mechanism. * Specification text to achieve the the goals described in the above scope. == Proposed List of Specifications == * OpenID Simple Registration Extension 1.1 (SREG 1.1) == Anticipated audience or users of the work == Implementers of OpenID Providers and Relying Parties. == Language in which the WG will conduct business == English. == Method of work == Work will take place primarily on the working group mailing list, with the possibility of conference calls and face-to-face meetings if deemed necessary by the working group. == Basis for determining when the work of the WG is completed == Proposed changes will be evaluated on the basis of whether they increase or decrease consensus within the working group. The work will be completed once it is apparent that maximal consensus on the draft has been achieved, consistent with the purpose and scope. Proposers: * Martin Atkins, Six Apart ([EMAIL PROTECTED]) * David Recordon, Six Apart ([EMAIL PROTECTED]) * ... Initial Editors: * Martin Atkins, Six Apart ([EMAIL PROTECTED]) * David Recordon, Six Apart ([EMAIL
Re: Proposing an OpenID Authentication 2.1 Working Group
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
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?
One parameter of PAPE was allowing the RP to specify how long it had been since the OP had authenticated the user. There is a PAPE working group right now, if you were interested in looking at how your suggestions would be incorporated, I am sure they would welcome you to the group. I've cc'ed Mike Jones who is one of the people driving PAPE -- Dick On 2-Jul-08, at 7:45 AM, Simon Josefsson wrote: Hi. Is there a best practice on how Openid consumers can find out whether re-authenticating the user, via the OpenID server, once in a while can lead to improved security? The security of normal one-time password systems (SecurID, SMS codes, Yubikeys, ..) can be improved if you ask for a new one-time password once in a while. Of course, the OpenID server cannot do this on its own, so it needs to be initiated by the OpenID consumer, but that will not happen without clues that it is a good idea to do perform re-authentication. Thoughts? Would this be a worthwhile addition to the openid-provider-authentication-policy-extension document? I'm thinking that the Response Parameters should include an optional parameter that imply that a one-time-password system was used, which suggests that the RP may re-authenticate the user more frequently. It may be useful to generalize this idea somewhat, but I can't come up with a better abstraction. Even re-authenticating using password may improve security in some situations (although I suspect most passwords are cached by browsers anyway these days). Ideas welcome. Thanks, Simon Btw, this idea originated from discussions on http://forum.yubico.com/viewtopic.php?f=9t=126. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RECOMMENDED: Proposal to create the PAPE working group
The specifications council recommends that the Foundation members approve the creation of the Provider Authentication Policy Extension (PAPE) working group, as proposed below. -- Dick On 22-May-08, at 3:25 PM, Mike Jones wrote: This message is being sent to revise the proposal to create the PAPE working group, changing only one word, so that the projected completion date is July 2008, rather than May 2008. The complete text of the revised proposal follows. --- Mike In accordance with the OpenID Foundation IPR policies and procedures this note proposes the formation of a new working group chartered to produce an OpenID specification. As per Section 4.1 of the Policies, the specifics of the proposed working group are: Proposal: (a) Charter. (i) WG name: Provider Authentication Policy Extension (PAPE) (ii) Purpose: Produce a standard OpenID extension to the OpenID Authentication protocol that: provides a mechanism by which a Relying Party can request that particular authentication policies be applied by the OpenID Provider when authenticating an End User and provides a mechanism by which an OpenID Provider may inform a Relying Party which authentication policies were used. Thus a Relying Party can request that the End User authenticate, for example, using a phishing-resistant and/or multi-factor authentication method. (iii) Scope: Produce a revision of the PAPE 1.0 Draft 2 specification that clarifies its intent, while maintaining compatibility for existing Draft 2 implementations. Adding any support for communicating requests for or the use of specific authentication methods (as opposed to authentication policies) is explicitly out of scope. (iv) Proposed List of Specifications: Provider Authentication Policy Extension 1.0, spec completion expected during July 2008. (v) Anticipated audience or users of the work: Implementers of OpenID Providers and Relying Parties – especially those interested in mitigating the phishing vulnerabilities of logging into OpenID providers with passwords. (vi) Language in which the WG will conduct business: English. (vii) Method of work: E-mail discussions on the working group mailing list, working group conference calls, and possibly a face-to-face meeting at the Internet Identity Workshop. (viii) Basis for determining when the work of the WG is completed: Proposed changes to draft 2 will be evaluated on the basis of whether they increase or decrease consensus within the working group. The work will be completed once it is apparent that maximal consensus on the draft has been achieved, consistent with the purpose and scope. (b) Background Information. (i) Related work being done in other WGs or organizations: (1) Assurance Levels as defined by the National Institute of Standards and Technology (NIST) in Special Publication 800-63 (Burr, W., Dodson, D., and W. Polk, Ed., “Electronic Authentication Guideline,” April 2006.) [NIST_SP800‑63]. This working group is needed to enable authentication policy statements to be exchanged by OpenID endpoints. No coordination is needed with NIST, as the PAPE specification uses elements of the NIST specification in the intended fashion. (ii) Proposers: Michael B. Jones, [EMAIL PROTECTED], Microsoft Corporation David Recordon, [EMAIL PROTECTED], Six Apart Corporation Ben Laurie, [EMAIL PROTECTED], Google Corporation Drummond Reed, [EMAIL PROTECTED] , Cordance Corporation John Bradley, [EMAIL PROTECTED], Wingaa Corporation Johnny Bufu, [EMAIL PROTECTED], Independent Dick Hardt, [EMAIL PROTECTED], Sxip Identity Corporation Editors: Michael B. Jones, [EMAIL PROTECTED], Microsoft Corporation David Recordon, [EMAIL PROTECTED], Six Apart Corporation (iii) Anticipated Contributions: None. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Using email address as OpenID identifier
On 1-Apr-08, at 11:15 PM, Paul E. Jones wrote: Dick, I’ll give you that one: that’s certainly easier. But, does not cause some confusion? After all, one’s identity is not yahoo.com, but that is the identity provider. Perhaps the prompts around the Internet ought to Say “OpenID Provider:” instead? :-) :-) ... that label would be more accurate. There is lots of work to be done to make OpenID simpler for users. I think that what will be easy for users is something provided by the browser that lets the user click to initiate a login or registration. No typing is better then any typing! Back when we started working on the protocols we could not expect this kind of functionality to be in the browsers. Now that awareness is higher, having it built into the browser is feasible. I of course am biased given the work we have done with Sxipper http://sxipper.com :) Presently, this variant works form some providers, but not most. I assume it’s due to the fact they’re not fully compliant with the spec yet? Or, is there some confusion as to how this ought to work? I don't think an OP is not OpenID 2.0 compliant if it does not take the OP as an identifier -- but I would have to reread to the spec to make sure. -- Dick ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OpenID and Yahoo
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
On 1-Apr-08, at 7:37 PM, Brad Fitzpatrick wrote: -- that said, with directed identity in OpenID 2.0, a user just needs to type in yahoo.com, or press the pretty yahoo button. No typing. I think this is why we don't need to use emails. People are very familiar with typing in a URL in the address bar. The experience of entering an URL and then being on that page is also really familiar. This is of course what happens when you type the OP into the OpenID prompt. Sorry for not being the least bit supportive of the email as identifier idea -- there are just so many things that are bad about it and the good reason (an identifier they already know) is provided per above with the advantage of giving an expected experience. I agree with Brad that we need to write a FAQ on this. -- Dick___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Using email address as OpenID identifier
On 1-Apr-08, at 10:02 PM, Paul E. Jones wrote: Dick, On this point, I really have to disagree. Even I rarely enter a URL into a web browser. Why bother when I know the web browser will figure it out for me. I don’t want to type http:// or https:// :-) I don't want to type the protocol either. I should have been more clear, the user types yahoo.com or aol.com into the prompt. Since this is NOT the identifier (which is a useful aspect of this method) -- the risks of NOT using https are much lower. -- Dick___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: RP generated nonce for stateful mode.
You point out the issue. A hash of the session-id is NOT a nonce. A nonce is required to prevent replay attacks. -- Dick On 19-Nov-07, at 8:19 PM, NISHITANI Masaki wrote: Hi everyone. OpenID 2.0 uses nonce generated by OP to identify the transaction. This seems very reasonable for stateless mode authentication, because OP is the entity which is responsible for protecting the stateless mode transaction from replay-attacks. In this case, it is not so difficult for OP to control nonce not to be used twice. On the other hand, for stateful mode, OP generated nonce is also used and RP assures the nonce should be uses only once this time. In general, it costs more for someone other than the generator to ensure using nonce once, than the genetator itself does it. Also in this case, RP should remenber every nonces during certain time referring timestamp on each nonce. Using RP generated nonce could simplify this. For example, RP only caliculate a hash value for the end-users session-id and send this to OP in auth_req. Then OP signs to the RP-genetated-nonce and send it back in auth_res, now RP can verify the sign with the session-id very easily. RP and OP do not need to remember nonces. Of cource this is not a nonce in strict meaning, and can be used more than once. But that parameter is valid only in the end-user's session. So if someone want to use the value for replay-attack, it should hijacks the session beforehand. So I wonder if this kind of idea has been discussed before or not, and if it has. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OpenID 2.0 finalization progress
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
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
I don't see why the two processes need to be any more dependant on each other then they are already. Having a final spec allows everyone with IP to be clear about any IPR statements they are making. In the IPR policy, participants have the option to withdraw when a spec is proposed to be final. I think it is currently embarrassing that we have not made OpenID 2.0 final. The OAuth project started from nothing to a final spec in the last six months. Now they are dealing with IPR. I'm not saying the IPR policy is not important, just that we don't need to deal with these issues serially. A number of participants are going to sit back until OpenID 2.0 is final AND the IPR has been settled. Let's at least knock one of these off and build up some more momentum! -- Dick On 17-Oct-07, at 7:26 PM, Johannes Ernst wrote: My understanding is that we need to get the IPR process finalized, then cross all the t's and dot the i's from the intellectual property perspective for the 2.0 spec(s), and then declare 2.0 to be final. Would be too embarrassing if we declared a spec final and then discovered that it did not meet our own IPR requirements re patents, for example, wouldn't it? On Oct 15, 2007, at 16:00, Dick Hardt wrote: +1 On 15-Oct-07, at 3:02 PM, Josh Hoyt wrote: Hello fellow OpenID spec participants, As I wrote in August [1], it's time to get the specification declared final. We've had quite a while now for implementations and specification feedback. Here at JanRain, we've implemented the draft specification in Python [2] and PHP [3], and I know that the folks at Sxip have implemented and deployed it in Java [4]. I know that at least those implementations have beed tested against each other, and worked successfully. I haven't heard of any new spec issues raised from implementation. As such, I am in favor of declaring Draft 12 the final draft and blessing it as OpenID 2.0. Do the other specification editors agree that now is the time to declare OpenID 2.0 finished? Josh Hoyt [EMAIL PROTECTED] OpenID: http://j3h.us/ 1. http://openid.net/pipermail/specs/2007-August/001953.html 2. http://openidenabled.com/python-openid/ 3. http://openidenabled.com/php-openid/ 4. http://code.google.com/p/openid4java/ ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OpenID Attribute Exchange Protocol questions
On 10-Jul-07, at 1:47 AM, James Henstridge wrote: On 10/07/07, Johnny Bufu [EMAIL PROTECTED] wrote: On 6-Jul-07, at 3:54 AM, James Henstridge wrote: Would that be appropriate to include in the spec or some best practices document? I see this as a pure OpenID (core) issue and don't feel the need to touch it in the AX spec. That would be appropriate if the OpenID authentication spec covered the idea of unsolicited OpenID responses. Given that it does not cover unsolicited responses and the AX spec uses them, it would seem sensible for the AX spec to describe in detail how they are meant to work. The appropriate place would be in the core spec so that other extensions would work the same way. -- Dick ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OpenID Attribute Exchange Protocol questions
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
On 10-Jul-07, at 10:52 AM, Johnny Bufu wrote: On 10-Jul-07, at 8:43 AM, James Henstridge wrote: On 10/07/07, Dick Hardt [EMAIL PROTECTED] wrote: Given that there doesn't seem to be any way to recover from this situation, it seems like private associations are the only sane option for unsolicited responses. An update message would require direct verification and not use an association. Associations are set by the RP, and in this case, the OP is initiating the conversation. I might be missing something, but I don't see how you can reliably use an association. That was the conclusion that I came to. I was replying to Johnny's statement that the OP knows the expiry time of the association handles it stores so could use a previously negotiated handle in the unsolicited response. I think it would be good to include a statement to this effect in the specification so that implementers don't have to work this out for themselves (and maybe get it wrong). Looks like it's already in the spec, in section 10, Responding to Authentication Requests: If no association handle is specified, the OP SHOULD create a private association for signing the response. The OP MUST store this association and MUST respond to later requests to check the signature of the response via Direct Verification. http://openid.net/specs/openid- authentication-2_0-11.html#responding_to_authentication That does not explain why no association handle was specified. I think adding language to explain that an OP may initiate a conversation and the message would be verified by Direct Verification as no association is available. -- Dick ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: No New DB Field Requirement? (WAS: RE: Questions about IIW Identifier Recycling Table)
It is more complex having to use two fields to uniquely identify a user in a DB then one. DB queries are more complex and there is more opportunity for the developer to make mistakes. Given a goal of OpenID is to be simple, one field is better then two. -- Dick On 8-Jun-07, at 10:14 AM, Johnny Bufu wrote: On 8-Jun-07, at 10:02 AM, Recordon, David wrote: I'm confused as to why a RP having to not create a new DB field is a requirement when looking to solve this problem. RP's implementations already need to change to upgrade from 1.1 to 2.0 and this has never been a requirement in the past. It certainly is nice that storage changes wouldn't be needed, but I don't see it as something that should be a requirement. My feeling was that, all other things being equal, some bits of code (stripping the fragment for display purposes) which ideally would go into the library, were preferred to requiring a schema change (to store the separate token) for the RPs. Not a requirement, but a strong preference. Johnny ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Do We Agree on the Problem We're Trying to Solve?
There are ways to solve B that don't really solve A. In fact, I think the only way to solve B that does not require a master directory is orthogonal to solving A. -- Dick On 8-Jun-07, at 10:49 AM, Johannes Ernst wrote: I would suggest that any solution to B is also very likely a solution to A. Anybody disagree? If so, I'd suggest that we should either solve A and B at the same time, or not at all. On Jun 8, 2007, at 10:42, Dick Hardt wrote: At IIW we[1] decided we wanted to solve (A) and that (B) would be nice to solve, but we were ok to wait for a future version to resolve, as when we discussed (B), resolving looked much harder then it seemed at first. I'm not certain of where we are now. -- Dick [1] those present when we met about how to solve recycling ... On 8-Jun-07, at 10:35 AM, Recordon, David wrote: I'm not sure if we all think we're trying to solve the same problem. The two problems that have been discussed are: A) Identifier recycling normally in large user-base deployments. i.e. insert big company needs a way to give 'TheBestUsernameEver' to a new user if it has not been used in some period of time. B) Losing control of your own domain name whether that be via someone stealing it or just that you don't want to have to pay for it forever. Have we made a decision as to if we're looking for a solution to solve both of these problems, only A, or only B? --David ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Do We Agree on the Problem We're Trying to Solve?
At IIW we[1] decided we wanted to solve (A) and that (B) would be nice to solve, but we were ok to wait for a future version to resolve, as when we discussed (B), resolving looked much harder then it seemed at first. I'm not certain of where we are now. -- Dick [1] those present when we met about how to solve recycling ... On 8-Jun-07, at 10:35 AM, Recordon, David wrote: I'm not sure if we all think we're trying to solve the same problem. The two problems that have been discussed are: A) Identifier recycling normally in large user-base deployments. i.e. insert big company needs a way to give 'TheBestUsernameEver' to a new user if it has not been used in some period of time. B) Losing control of your own domain name whether that be via someone stealing it or just that you don't want to have to pay for it forever. Have we made a decision as to if we're looking for a solution to solve both of these problems, only A, or only B? --David ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Do We Agree on the Problem We're Trying to Solve?
Multiple, redundant identifiers solves B without requiring a master directory. On 8-Jun-07, at 11:06 AM, Johannes Ernst wrote: Such as? On Jun 8, 2007, at 10:55, Dick Hardt wrote: There are ways to solve B that don't really solve A. In fact, I think the only way to solve B that does not require a master directory is orthogonal to solving A. -- Dick On 8-Jun-07, at 10:49 AM, Johannes Ernst wrote: I would suggest that any solution to B is also very likely a solution to A. Anybody disagree? If so, I'd suggest that we should either solve A and B at the same time, or not at all. On Jun 8, 2007, at 10:42, Dick Hardt wrote: At IIW we[1] decided we wanted to solve (A) and that (B) would be nice to solve, but we were ok to wait for a future version to resolve, as when we discussed (B), resolving looked much harder then it seemed at first. I'm not certain of where we are now. -- Dick [1] those present when we met about how to solve recycling ... On 8-Jun-07, at 10:35 AM, Recordon, David wrote: I'm not sure if we all think we're trying to solve the same problem. The two problems that have been discussed are: A) Identifier recycling normally in large user-base deployments. i.e. insert big company needs a way to give 'TheBestUsernameEver' to a new user if it has not been used in some period of time. B) Losing control of your own domain name whether that be via someone stealing it or just that you don't want to have to pay for it forever. Have we made a decision as to if we're looking for a solution to solve both of these problems, only A, or only B? --David ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Do We Agree on the Problem We're Trying to Solve?
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?
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?
You are still trusting one registry. Of course it is your choice, but you have a single point of failure. Do you think they will still be around in 50 years? On 8-Jun-07, at 4:20 PM, Recordon, David wrote: I don't see how it requires a centralized registry, if I choose to trust that LiveJournal, or some ugly URL from AOL, etc will never go away then that is my choice. --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dick Hardt Sent: Friday, June 08, 2007 4:08 PM To: Drummond Reed Cc: specs@openid.net Subject: Re: Do We Agree on the Problem We're Trying to Solve? On 8-Jun-07, at 4:00 PM, Drummond Reed wrote: Drummond Reed wrote: Multiple, redundant identifiers is what canonical ID mapping provides. It doesn't require a master directory; it's as distributed as OpenID itself, i.e., it simply provides a way to map a reassignable URL or XRI to a persistent URL or XRI. Dick Hardt wrote: The persistent URL or XRI *is* a master directory. What do you do when the persistent identifier is compromised, goes out of business ... That is problem B. Canonical IDs do not solve B. I completely agree that B is a hard problem. However Canonical IDs solve B if the identifier authority for the Canonical ID follows business and operational practices intended to solve B. And I think there is a solution that does not require a single, central registry. One of the other issues with the registry is it is challenging to provide directed identities. -- Dick ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Attribute Exchange external reference?
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
On 4-Jun-07, at 7:51 AM, Granqvist, Hans wrote: So I ask again - does anyone see any issues with the fragments being used like this: http://openid.net/pipermail/specs/2007-May/001767.html Seems reasonable in essence. But it adds complexity and removes some immediacy of URL identifiers-as-is. Do fragments need special handling just to handle id recycling risks? I'm probably missing some context, but can't the issuing OP make sure to issue unique IDs, like http://example.com/user1234 instead of http://example.com/user#1234 ? Just to clarify the issue: Users like to have memorable usernames, and likely memorable OpenIDs. So http://example.com/hans would be a desirable URL at example.com. For OPs with literally 100Ms of users, http://example.com/hans would be a coveted URL and if it is not being used, example.com would like to issue it to someone else. I think the tradeoff of RPs understanding to strip fragments when displaying them is worth removing a barrier for very large OPs from joining OpenID. -- Dick ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Specifying identifier recycling
On 3-Jun-07, at 2:14 AM, Recordon, David wrote: Overall, I'm not sure we are ready in this community to pick one alternative over another as the standards. I have my views, (many) others have (many) others -- and I don't think that any of this has to be in an Authentication 1.x (x1) or 2.0 spec, whatever it will be. This seems like a clean add-on. I also agree with Johannes here. I'd like to see this written as an extension so that if the first approach doesn't work, the Auth spec itself doesn't have to be reverted. Rather we can finish 2.0 and try implementing different approaches before deciding on the final way to solve this problem. I don't see how we can solve this problem as an extension as we need the RP to know that a memorable identifier has some extra info that makes it unique when reused. This is core to OpenID. -- Dick ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Specifying identifier recycling
There is a huge difference between the OP/RP shared secret and using a shared secret as an identifier. The secret between the OP and RP has a mechanism for it to be recycled. If it happens to be lost, then the pair can set up a new secret. If the user's secret is lost, then that identifier and any accounts that it was used for are lost. -- Dick On 31-May-07, at 7:30 AM, Johannes Ernst wrote: If we cannot assume that nobody manages to obtain a secret they should not have gotten in the first place, then OpenID as it stands is rather useless as we cannot trust its authentication scheme. Note that the surface through which the D-H shared secret can escape is about twice as large as the surface through which a private key can escape -- because an RP does not have access to the private key. In other words, if I was an attacker, I'd go after a lot of things first before I'd try to obtain a private key. Note also that public keys would make rather good i-numbers -- for those who would like to, they can ignore that they are public keys and do i-number-based verification only, because they are simply numbers. For those who don't care about i-numbers, they use their public key aspects. Win-win, perhaps? There is also the case -- which Stefan Brands would undoubtedly bring up if he was on this list -- that the IdP may be hostile, or may become hostile. (think of, say, a large OpenID provider going out of business, and being bought out by spammer.com -- or just the domain name whose registration lapsed) A scheme that is public key based is inherently more resilient towards this than one that is not. You certainly don't want to trust spammer.com to honor whatever conventions the previous owner of the domain put in place to disambiguate their users. -- Overall, I'm not sure we are ready in this community to pick one alternative over another as the standards. I have my views, (many) others have (many) others -- and I don't think that any of this has to be in an Authentication 1.x (x1) or 2.0 spec, whatever it will be. This seems like a clean add-on. On May 30, 2007, at 22:01, Drummond Reed wrote: Johannes: What about the point Dick posted earlier in this thread, that the problem with using a public key is if the private key gets compromised? Persistent identifiers need to persist independent of any attribute changing or being revoked. =Drummond -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Johannes Ernst Sent: Wednesday, May 30, 2007 9:54 PM To: OpenID specs list Subject: Re: Specifying identifier recycling On May 30, 2007, at 21:02, Johnny Bufu wrote: ...The bottom line is that it can't be done easily - a mechanism similar to XRI's canonical ID verification would have to be employed, to confirm that the i- number actually 'belongs' to the URL on which discovery was initiated. (Otherwise anyone could put any i-number in their URL- based XRDS files.) Public keys ... public keys ... with the added benefit that no centralized or trusted verification service needs to be employed whatsoever ... Johannes Ernst NetMesh Inc. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Proposal for Recycling Identifiers in OpenID 2.0
The issue you bring up is a separate issue then the motivation for recycling identifiers by large OPs. Your point is how does a user transfer from one identifier to another. The issue at hand is the scarcity of namespace. -- Dick On 14-May-07, at 8:48 AM, Johannes Ernst wrote: These seems to be an assumption on this thread that - identifiers at the same domain name get recycled often (e.g. example.com/jim) - domain names don't get recycled often (e.g example.com itself) I would suggest that any proposed solution needs to be able to deal with domain names as well that aren't being renewed, and picked up by somebody else. Somebody who isn't necessarily continuing any kind of naming scheme the previous owner had in place, or who is actively hostile with respect to the previous owner. There's a whole industry out there recycling domain names -- which proves that this is an issue. Johannes Ernst NetMesh Inc. openid-relying-party-authenticated.gif lid.gif http://netmesh.info/jernst ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Proposal for Recycling Identifiers in OpenID 2.0
On 14-May-07, at 10:10 AM, Johannes Ernst wrote: On May 14, 2007, at 9:12, Dick Hardt wrote: The issue you bring up is a separate issue then the motivation for recycling identifiers by large OPs. What I'm saying is a superset of the issue discussed so far that ought to use the same technical solution because the problem is the same: X used identifier Y, and now Z controls Y. What now? Your point is how does a user transfer from one identifier to another. While related, that's not the issue I was talking about. But you are right in that all of those problems should be solved at the same time. I'm not saying they should all be solved at the same time. I think they are different problems and can be solved in different ways. -- Dick ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Proposal for Recycling Identifiers in OpenID 2.0
I had the good fortune of discussing URIs, URLs, fragments and the recycling issue with a number of smart W3C people at WWW2007 and they did not respond with horror at the concept of using fragments to recycle identifiers. Given this is a requirement for large OPs, here is a proposal. A number of details and issues remain, suggestions and constructive criticism encouraged! -- Dick Motivating use case: For large OPs, user identifier namespace is a scarce resource and they need to be able to recycle human readable identifiers Design Considerations: + Existing identifiers continue to work + A human readable, memorable identifier can be entered by the user and displayed to other users + A globally unique identifier is user by RPs that is different for different users of the same human readable identifier Proposed Solution: Allow fragments to be an optional part of the identifier. An RP could display the URL sans fragment to the users of the website. RPs would use the complete URL including fragment to identify users. RPs would be able to delete other accounts with the same base URL when seeing a new fragment. (do we want to allow this?) With OpenID 2.0, the identifier entered by the user does not need to be the same as the identifier returned by the OP To login to an RP, the user could enter openid.op.com/user and if the complete identifier managed by the OP was http://openid.op.com/ user#7356, this is what would be returned. The following two identifiers returned by an OP would be considered different by an RP: http://openid.op.com/user http://openid.op.com/user#7356 Although the user would enter openid.op.com/user or openid.op.com in the OpenID prompt at the RP. Outstanding Issues: When resolving http://openid.op.com/user#7356;, does the RP resolve just http://openid.op.com/user or is does the RP need to find the fragment 7536 in the document at http://openid.op.com/user;? If so, where is the fragment? Does it need to occur before. What does it mean when the document type is an XRDS document? Does the document need to contain http://openid.op.com/user#7356; for the RP to close the circle on what the OP is stating? Will this break existing OpenID 1.1 RPs? Which ones? Is this going to be an issue for them? ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: encoding newlines in attribute values
On 20-Apr-07, at 11:05 AM, Douglas Otis wrote: On Apr 20, 2007, at 10:56 AM, Johnny Bufu wrote: On Apr 19, 2007, at 10:46 AM, Josh Hoyt wrote: Each attribute already has to define its encoding rules and data- type. The mechanism for encoding a newline can be part of this encoding, if newlines are allowed in the value. Once there is one attribute that has a defined encoding for newline, when new attributes are defined, they can re-use this encoding. Does that sound reasonable? So are you proposing that AX only accepts strings without newline characters in them, and the encoding to such a string should be handled by the parties who actually consume the attributes, according to the type / metadata specs? This would be nice and simple for the AX itself, however it would require everyone defining attributes to also define a 'encoding to strings without newlines' for them. The use of base64 can be confined to individual elements within an attribute where newlines are _not_ affected. There should be a standardized template for declaring base64 encoding starts with 'X' and ends with 'Y'; Great idea Douglas. To expand on that and include Mark Wahl's proposal about locale encoding[1] in a standard way for attributes so that the libraries can do the right thing 99% of the time. I would propose that AX data have a default encoding that can be overrode by the attribute metadata. The default would be: URL encoding for text data escape sequence for locale using mechanism in RFC 3866 escape sequence to indicate binary data that is then base64 encoded [1] I see that Mark's proposal is not up on the site yet. It is a good proposal though! ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
axschema.org instead of openid.net
Thanks everyone for feedback on using schema.openid.net. Here are my conclusions: 1) A number of people would like to be using a web oriented schema right away and don't want to wait for other groups to create the schema. 2) A number of people are allergic to the openid.net domain being used for things that are not openid.net protocol specific. Sxip has acquired axschema.org (Attribute eXchange schema :-) and we will host the site and a mail list as a service to the community and operate it per http://openid.net/specs/openid-attribute- types-1_0-02.html If I don't hear from anyone that they don't like this idea, then we will set this up next week. -- Dick ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: [dev-monkey] Newlines in bio attribute
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
btw: my main driver in stating +1 is that I was concerned with how it would be implemented, and given that Mark has the one working parser and is ok with it, then my concern has disappeared! On 10-Apr-07, at 5:52 PM, Dick Hardt wrote: Good argument Mark, I concur. +1 -- Dick On 10-Apr-07, at 4:52 PM, Mark Wahl wrote: Section 4.3 of http://openid.net/specs/openid-attribute-types-1_0-02.html suggests that in URIs defined for attributes for OpenID AX, URI fragment specifiers should not be used. Now I'm no RDF expert, but I'm in favor of allowing fragments, and perhaps even encouraging them. I'd prefer this statement be removed from subsequent versions of the OpenID AX, in order to not dissuade other schema developers from using fragments. Here are some points for discussion on that topic, I'd be interested in hearing feedback esp. from other RDF implementors. 0. Some servers will have but a single, small, fixed schema. I'd rather those servers be able to reference and serve a single RDF file with their complete schema, instead of needing to break that schema into a bunch of little schemas. For example, suppose a server only supports FOAF. Now FOAF does not use fragments for the property definitions for its attribute types, but the attribute types defined in FOAF are not currently resolvable to an RDF document that describes those attribute types. If xmlns.com where the FOAF RDF is hosted were to implement having these attribute type URIs used in FOAF be resolvable, they would either need to - create a few dozen little RDF files that together mirror the content of foaf.rdf, or - implement a URI rule that http://xmlns.com/foaf/0.1/* returns foaf.rdf If I were redefining FOAF, I'd have its attributes be defined as fragments, so that there is only one base URI for the FOAF schema. (Also to give them RDF class definitions, see below). 1. It appears to be current practice for RDF representations of metadata for attributes in Higgins to use fragments. In OWL-based systems, the RDF object at the base URI of the document is an OWL Ontology. In Higgins, which uses OWL, the object at the base URI is an OWL Ontology that 'imports' the Higgins Ontology. The RDF file for an attribute contains an OWL Class for the attribute named by a fragment,e.g., #Firstname, and several related OWL properties and RDF instances in that same file that add structure to that class. 2. In our 'schemat' implementations which attempt to generate RDF for existing schemas of 'legacy'/'installed base' protocols, it is desirable to be able to have additional, named OWL classes, RDF objects, and other modelling and descriptive data definitions that are shared across multiple attributes of a single schema. For example, a schema may define its own value syntax and matching rules, and wish to share those syntaxes and matching rules across the attributes of that schema. It would be desirable if there could be a single RDF file which contains the attribute type metadata, the syntax definition and matching rule definition, rather than needing to have the attribute type metadata in a set of files that are separate from the syntax definitions and matching rule definitions, or are duplicated in those files. 3. I find that in our implementation 'schemat' of identity metaschema attribute metadata retrieval that is a definite performance gain if all the schema elements for a particular schema can be retrieved in a single HTTP GET. It is likely that an implementation interested in an attribute Firstname of a particular schema would also be seeing a few other attributes Lastname, Middlename etc of the same schema, and it would be good if a GET that retrieves the data for Firstname also gives the implementation the rest of the schema so that it does not need to keep going back and GETing for each attribute type. 4. Requiring that each be in a separate document would likely lead to duplication of metadata, particularly Dublin Core metadata that describes the schema as a whole. I feel it would be better if the RDF object at the base URI has the Dublin Core metadata for the schema as a whole, and that the Attribute Type Metadata is a class named by a fragment below that base URI. 5. (appeal to authority) http://www.w3.org/DesignIssues/Fragment.html This means that identifiers for arbitrary RDF concepts should have fragment identifiers. Mark Wahl Informed Control Inc. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: PROPOSAL schema.openid.net for AX (and other extensions)
On 9-Apr-07, at 5:24 PM, Recordon, David wrote: Yes, I agree an upgrade path from SREG is needed. We could however do something as simple as http://openid.net/specs/openid-simple-registration- extension-1_0.html#ni ckname for the existing SREG fields. by making this a fragment, you force a requirement that Mark's tool has to be able to dig into a document and find the anchor as opposed to the attribute being self contained -- a complication I am not sure we want to deal with at this point in the meta-data why not have a page that maps the existing SREG to the AX attributes we have already defined? why create yet-another set of attributes? Myself, I think a developer would like to look in ONE place to find all the common web related attributes she will likely need so that she can build her app and not have to go looking across a dozen different sources to write some code. There will definitely be attributes that are for specific communities, so the developer will need to look in a few places, but why make it harder then it needs to be at this point in time? A number of people have spoken up to vote +1 to use schema.openid.net. Given that you have the magic wand David, are you going to let the community progress or do we have to keep arguing with you until one party wears out and gives up? -- Dick ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Web Access Management
Deal with the IPR issue ... On 9-Apr-07, at 12:54 PM, McGovern, James F ((HTSC, IT)) wrote: So, what will it take to move the mentioned vendors from simply being aware to actively participating? -Original Message- From: Dick Hardt [mailto:[EMAIL PROTECTED] Sent: Sunday, April 08, 2007 2:48 PM To: McGovern, James F (HTSC, IT) Cc: specs@openid.net Subject: Re: Web Access Management Tony Nadalin from IBM and Dale Olds from Novell are well aware of what is happening in OpenID. The lack of a clear IPR policy is preventing Microsoft from directly participating in the mailing lists. A number of us met at Microsoft [1] and this was one of the issues that we are working to address. btw: I think this is a better topic for [EMAIL PROTECTED] rather then specs ... [1] for the conspiracy minded, nothing happening behind closed doors, the meeting was publicly announced and anyone was welcome to attend. A number of us are kicking ourselves for not taking good notes that we could post to the list. -- Dick ** *** This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies. ** *** ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: PROPOSAL schema.openid.net for AX (and other extensions)
The list is a set of xml files that we wanted to post on schema.openid.net so that everyone could see them per the proposed draft. Each attribute has a chunk of meta data around it. ( the files are all viewable and browsable as well as being machine readable) A good OP would dynamically add new attributes as they become available as opposed to statically coding a set. If you would be kind enough to let us set up schema.openid.net, then we could more easily show everyone. -- Dick On 9-Apr-07, at 8:23 PM, Recordon, David wrote: Is there a list anywhere? I didn't find one in the documents and I think this list would benefit everyone in the conversation. I'm just curious as to the fields you're expecting an OP to implement. --David -Original Message- From: Dick Hardt [mailto:[EMAIL PROTECTED] Sent: Monday, April 09, 2007 07:12 PM Pacific Standard Time To: Recordon, David Cc: James Walker; Martin Atkins; Mark Wahl; OpenID specs list Subject:Re: PROPOSAL schema.openid.net for AX (and other extensions) On 9-Apr-07, at 5:24 PM, Recordon, David wrote: For new fields, is there a reason we can't use the ldap.com URLs Mark posted as a starting point? I know Dick said they didn't cover all the needed attributes, but would it be good enough to start with and then expand from there possibly on schema.openid.net? Dick, do you have a list of attributes you see as needed for the first implementations of AX (I couldn't find one in the current AX specs though I fully admit I may be looking in the wrong place)? There are many, many attributes that we are using in AX that are not in LDAP, or don't have the granularity. -- Dick ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Web Access Management
Tony Nadalin from IBM and Dale Olds from Novell are well aware of what is happening in OpenID. The lack of a clear IPR policy is preventing Microsoft from directly participating in the mailing lists. A number of us met at Microsoft [1] and this was one of the issues that we are working to address. btw: I think this is a better topic for [EMAIL PROTECTED] rather then specs ... [1] for the conspiracy minded, nothing happening behind closed doors, the meeting was publicly announced and anyone was welcome to attend. A number of us are kicking ourselves for not taking good notes that we could post to the list. -- Dick On 5-Apr-07, at 12:00 PM, McGovern, James F ((HTSC, IT)) wrote: The RSA CTO is Bret Hartman, the Netegrity CTO is Vadim Lander. I would also suggest inviting Marc Wilcox from Oracle. I don't know the names of folks from Novell or IBM. Would be great if Dick reached out to them. -Original Message- From: Hans Granqvist [mailto:[EMAIL PROTECTED] Sent: Thursday, April 05, 2007 1:05 PM To: Dick Hardt Cc: McGovern, James F (HTSC, IT); specs@openid.net Subject: Re: Web Access Management Ping demoed OpenID technology at RSA. I hear Novell and IBM are looking at supporting OpenID. Microsoft has said they will in future products. Oracle and CA are following OpenID. So, yes. :-) I'm curious why almost all of these companies are non-existent on the mailing lists. Any insights? -Hans ** *** This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies. ** *** ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Promoting OpenID
On 5-Apr-07, at 8:46 PM, Johannes Ernst wrote: On Apr 5, 2007, at 18:36, Chris Messina wrote: ... I personally think selling to the enterprise is nearly impossible without tons of grassroots adoption ... I disagree. ;-) Now granted, there are many, many things that we all need to do and that need to happen to make OpenID suitable for the enterprise market on a mass market basis. People like James keep reminding us of that on this list and in other places, and please keep it coming. But it's definitely not the case any more that it is impossible... I think you are missing a key part of Chris statement ... without tons of grassroots adoption ... If the grassroots don't support OpeniD, very unlikely that the enterprise will. -- Dick ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: PROPOSAL schema.openid.net for AX (and other extensions)
Hi Mark The URL mapping of LDAP attributes below looks pretty useful. Some of those overlap with attributes we defined for AX, but many of the attributes in AX are not defined, or don't have the same granularity. Given that LDAP attributes were defined per the needs of enterprise, and AX attributes reflect the attributes commonly requested on public web forms, this is to be expected. With a goal of making it easy for people to use AX, I'd like to have a list of common web oriented attributes readily available for developers to work with. What do you think of using the equivalence mechanisms to map common attributes between the two sets, but allowing the two sets to maintain their focus on solving the problems for their separate communities? ... or do you think we should try and come up with a master set of core attributes? -- Dick On 8-Apr-07, at 1:01 PM, Mark Wahl wrote: Dick Hardt wrote: If there was something out there already, I would propose we used it. There is not. Just like the SAML crowd has accused the OpenID crowd of reinventing an identity protocol (AKA reinventing the wheel) -- the AX proposal has some unique concepts that people like Paul and Mark think are quite innovative. Other schemas don't support them. I have cc'ed Paul and Mark in case they can point to some new work that we can take advantage of today. FYI if you are carrying attribuets in OpenID AX that are equivalent to LDAP attributes with attribute types being standardized in the IETF, then you could use our LDAP schema definition metadata. We have resolvable HTTP URIs for each of the widely-deployed attributes, such as givenName. Background: In order to get some test data for developing our Schemat 'reference implementation' of identity metasystem schema management tools, we (Informed Control) have been generating metadata for the LDAP/X.500 schema definitions that are in IETF RFCs. For our first cut, we took the definitions from these RFCs: 2079 Definition of an X.500 Attribute Type and an Object Class to Hold Uniform Resource Identifiers (URIs). M. Smith. January 1997. (Format: TXT=8757 bytes) (Status: PROPOSED STANDARD) 2798 Definition of the inetOrgPerson LDAP Object Class. M. Smith. April 2000. (Format: TXT=32929 bytes) (Updated by RFC3698, RFC4519, RFC4524) (Status: INFORMATIONAL) 4512 Lightweight Directory Access Protocol (LDAP): Directory Information Models. K. Zeilenga, Ed.. June 2006. (Format: TXT=108377 bytes) (Obsoletes RFC2251, RFC2252, RFC2256, RFC3674) (Status: PROPOSED STANDARD) 4519 Lightweight Directory Access Protocol (LDAP): Schema for User Applications. A. Sciberras, Ed.. June 2006. (Format: TXT=64996 bytes) (Obsoletes RFC2256) (Updates RFC2247, RFC2798, RFC2377) (Status: PROPOSED STANDARD) 4524 COSINE LDAP/X.500 Schema. K. Zeilenga, Ed.. June 2006. (Format: TXT=11245 bytes) (Obsoletes RFC1274) (Updates RFC2247, RFC2798) (Status: PROPOSED STANDARD) and generated RDF/XML files with metadata translated into OWL from the LDAP representation. (We picked those RFCs since there was already a change control and standardization process for them, they represented rough concensus as a minimum interoperable set of definitions, the objectclasses in them are stable, these schemas are widely supported by many LDAP servers as a native schema, and contained the schema used in example LDIF/DSML files. There are certainly other non-obsolete RFCs containing LDAP schemas, which we'll address later as there's interest; I don't think there's any technical limitations that would have prevented us from extracting metadata from them). For each LDAP attribute type definition in those RFCs, the schemat tool generated an OWL DatatypeProperty and a OWL Class. The URI of the OWL class generated from an LDAP attribute type is currently of the form http://www.ldap.com/1/schema/rfc.owl#AttributeType_OID where is the number of the RFC, and OID is the string encoding of the attribute's object identifier. (We chose to use the OID in the URI, rather than a string, since LDAP allows an attribute to have multiple string names, and does not have a 'primary' string name. Having to equivalentClass between multiple Classes for a single LDAP attribute type definition seemed worse than having one Class with an identifier already known to be unique). We chose the ldap.com domain name as we have it :-) and these are LDAP-developed definitions; I'm not wedded to the ldap.com domain name, and considered two alternatives: - using an 'oid' URI form This would be a suitable alternative URI, however, this would introduce a dependency on a oid URN namespace resolver, which isn't yet operational. - using an ietf.org or iana.org domain name This would be our preferred long-term strategy
Re: some questions on OpenID AX 1.0 draft 4
Hi Mark, for some reason I just saw this post, answers and questions inserted ... On 5-Apr-07, at 9:47 AM, Mark Wahl wrote: http://openid.net/specs/openid-attribute-exchange-1_0-04.html 1. Section 2 states that the store operation saves or updates attribute information on the OpenID Provider. How does an RP delete an attribute when updating information on the OP? The OP is not a repository for the RP. It is a repository for the user. RPs store data at the OP that the user might find useful somewhere else. 2. Section 3.2 states that If an attribute type identifier URI can be resolved then it MAY be dereferenced to retrieve a description of the property. In this protocol, who is doing the dereferencing? Would an OP return an error during a store if it resolved the URI and there was no description of the property there? This feature was created to allow an OP to dereference an attribute requested by an RP that the OP did not understand and dynamically assist the user in providing the attribute. The meta-data could provide labels and syntax so that the OP could prompt the user for the value, or the meta-data could indicate to the OP where the user could go do get the attribute. 3. Section 3.3 states that an attribute value MUST be a UTF-8 string. Are any UTF-8 characters permitted? How is a newline escaped, as Section 4.1.1 of http://openid.net/specs/openid- authentication-2_0-10.txt states that A key or value MUST NOT contain a newline. escaping of chars if needed is dependent on the syntax of the data in the attribute. The idea this was out of scope of AX and dependant on specific attributes. Presumably RFC 2482 characters (plane 14 language tags) are OK? Or are language tags of values carried through some other means? UTF-8 would preclude language tags would it not? How can the RP determine the maximum value length that an OP will support for a particular attribute? no upper limit defined ... suggestions? 4. Section 5.1 states that Attribute aliases MUST NOT contain newline and colon characters,... they also MUST NOT contain commas. What is the significance of a period character? Can an alias contain a period? no -- looks like that should be added to the spec What is the maximum length of an alias string that an RP can expect an OP to support? suggestions? 5. Section 5.1 states that if openid.ax.if_available parameter is present The OpenID Provider MAY provide the identity information specified in this parameter.. How does the RP determine the schema of the provider to know what to ask for? Don't understand this question. 6. Section 5.1 states that openid.ax.count.alias is the number of values for the specified attribute alias the Relying Party wishes to receive from the OpenID Provider. If present, the value MUST be greater than zero. If absent, exactly one value is requested. OpenID Providers MUST NOT return more than the number of requested values. What is the largest value of count that an RP that wants all values can submit that an OP will support? 2^31? 2^32? 2^63? See thread with Josh. Suggested value? 7. Section 5.2 states that The value of the openid.ax.type.alias parameter specifies the type identifier URI for the attribute referred to as alias. MUST be present if, and only if, this exact parameter was included in the fetch request. It's not clear to me how subtyping of attributes is handled. Suppose the OP holds a 'person' with attributes ldap:///cn=schema#cn: John Smith ldap:///cn=schema#cn: Johnny Smith ldap:///cn=schema#surname: Smith ldap:///cn=schema#givenName: John ldap:///cn=schema#patronymic: Paul Now the attribute types ldap:///cn=schema#cn, ldap:///#cn=schema#patronymic, ldap:///cn=schema#surname, ldap:///cn=schema#givenName are all subtypes of a generic attribute type ldap:///cn=schema#name. In LDAP directories, when one asks for a 'name' attribute, that's a shorthand for asking for any of the naming attributes, which can be useful if the requestor doesn't know in advance what schema attributes the server uses for naming people. A RP issues a fetch request for ldap:///cn=schema#name, asking for any naming information . The OP doesn't have a #name attribute in that person, but does have #cn, #surname, #patryonmic and #givenName attributes. How should the OP encode these types in the fetch response to the RP? AX has a simple model that you ask for an attribute and you get it. If the meta-data states that different types are equivalent, then you can get one of those. 8. Section 6.1 states that openid.ax.value.alias assigns a value to the attribute referred to as alias. Is an OP receiving a store response required to save the alias provided by the RP for any purpose, or is the alias merely used in a particular protocol interaction? alias is just for the
Re: Moving AX Forward (WAS RE: SREG namespace URI rollback)
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)
On 5-Apr-07, at 9:24 AM, Recordon, David wrote: Dick, see my other message but this is not about ME stopping you! We wanted to publish them on the website so that other people could look at them, but you did not want to do that, and you control the domain. Dick, that isn't a fair statement at all. It is not my decision to make if schemas.openid.net should be created and the content you're proposing put there. I've asked you multiple times to have a conversation on this list ending in a formal vote (like we've done for many other spec decisions) to make this decision. If I've missed this vote then please point me at it. I'm quite honestly not sure what more to say. If you want to see this work happen then you need to take the initiative and make it happen. You can't just expect to post a few messages to the ID Schemas list and have them magically start working. I'm all about taking advantage of existing momentum, but I have a hard time seeing anyone who cares about AX being unwilling to have this discussion as a part of the ID Schemas community. If there is anyone, I'd certainly like to understand the reasons why (beyond it being hard). We wrote a spec. We have working code. Other people have developed code as well. We need to publish a schema so that we can systems talk to each other. If *you* would like to see the work done over in ID Schemas, then *you* can work to make it happen there. The same for other people. If the work shifts to there, I am fine with it. Right now, I'm fine with doing the work here on the OpenID specs list. -- Dick ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
PROPOSAL schema.openid.net for AX (and other extensions)
OpenID Attribute Exchange (AX) uses URLs to uniquely identity attributes. The URLs are resolvable to provide meta data that is both machine and human readable. In order to do anything useful with AX, some commons identity attributes need to be defined. I would propose that we start off using URLs based off of schema.openid.net. The Metadata model has provisions for stating that a given URL is equivalent to another one, so that if and when a more authoritative source is available, the schema.openid.net URLs can reference a source that would be considered more appropriate. ie. we are not locked forever to the schema.openid.net domain. Is there a better domain that could be used? Likely, but as a community we have control over openid.net and we can make this happen now so that we can move forward with development. Issues? -- Dick ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: PROPOSAL schema.openid.net for AX (and other extensions)
If there was something out there already, I would propose we used it. There is not. Just like the SAML crowd has accused the OpenID crowd of reinventing an identity protocol (AKA reinventing the wheel) -- the AX proposal has some unique concepts that people like Paul and Mark think are quite innovative. Other schemas don't support them. I have cc'ed Paul and Mark in case they can point to some new work that we can take advantage of today. Other responses inserted: On 6-Apr-07, at 11:49 AM, Recordon, David wrote: As I've stated in the past, I have no problem with using schema.openid.net to define attributes such as the authoritative URI for an OpenID URL, i-name, etc. I do have a problem with using this namespace to define an attribute such as a First Name. I do not feel that this community should be dealing with all of the issues such as First Name vs. Given Name, as that is not where the expertise is, let alone it has been done in the past. I also strongly believe that due to the number of other definitions of these attributes, either we as a community should decide to use one of them or work with a project such as ID Schemas to create a set of URIs not tied to the OpenID project that solves both our needs and the needs of others. I do not particularly care where this work would happen and as I've said in the past, I'd be fine with someone just buying a domain to do the work to preserve the speed for getting this bootstrapped while not tying it to OpenID. If really don't care, then you should not care if it is happening in OpenID then. First Name: - http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname This URL could be used. To date they have not made these self describing. Who knows what this is? The AX proposal is to make the URLs describing. This makes it easier for programmers to know what it is they are working with. - http://xmlns.com/foaf/0.1/firstName - http://xmlns.com/foaf/0.1/givenname Both of these are elements in a larger XML document. This is not the model of AX. - http://en.wikipedia.org/wiki/First_name While intriguing to have wikiality define terms, this is not practical since the definition needs to be static or code will break I'm sure if Paul Trevithick or Mark Whal join this conversation they'd be able to highlight even more URI definitions of a First Name than I was in a cursory search. This also isn't including all of the work done for things such as LDAP, vCard, or others listed at http://idschemas.idcommons.net/moin.cgi/List_Of_Schemas in defining what these schema attributes are and mean. Most other work has created closed schemas. The AX proposal is an open schema where anyone can define a new attribute and each one is self describing. If we want to create URLs for attributes from an existing schema (such as LDAP or vCard) since easy URLs do not currently exist, then that is one thing. Creating an entirely new definition of commonly used attributes IMHO is unacceptable. People keep doing it for a variety of reasons. People keep inventing new programming languages. We should be reusing anything that we can, not inventing something new especially given the complexity of this particular task. The task has largely been done. Still need to finalize the meta-data file format. I'm not sure what more I can do to urge this community to not reinvent the wheel in this area. See comment at top. AX does not need a wheel. AX needs a wing. Wings don't exist right now. -- Dick ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: PROPOSAL schema.openid.net for AX (and other extensions)
The work is not rooted in openid.net. We are starting there. We can easily point those definitions somewhere else later, but we need somewhere to start. Given that the community that cares today is in OpenID, and the domain the community has is openid.net, it would make sense to use that domain. A different domain is going to have the same issues of control. I would expect that other members of the community would have concerns if it was rooted at say sxip.org. Happy to have further discussions at IIW, but don't see why the work here should wait until then. Other communities may or may not want to take advantage of what we are doing, and it will be easier for them to understand what we have if we have working code then just more talk about it. To take a step back, the people to decide this should be the people that are doing implementations. Would you clarify David if *you* are implementing, or just sharing your opinion? If anyone implementing would like to do something different, then I'd welcome additional discussion, otherwise I think we should be able to move forward with the proposal. -- Dick On 6-Apr-07, at 2:03 PM, Recordon, David wrote: I think it is great that there is new and innovative work in what you've been doing. I would also think that it would benefit the entire user-centric (and even non-user-centric) community to take advantage of this work regardless of the technology. By having it rooted on openid.net, I think there will be aversion to doing so and other communities will rather jump to the conclusion that the OpenID community is yet again reinventing the wheel by defining common core attributes. This is what I want to avoid. By doing this in a neutral location, not tied to a specific identity technology, it removes this concern as well as does more good for the entire ecosystem. If the ID Schemas project is not the right place to do it, then I see no reason not to create one; I would be happy to front the cost of a domain name if needed. I'd also think this would be something worth discussing at IIW when the entire community comes together. I would really like to see this be something that can be used by OpenID, CardSpace, Higgins, SAML, etc. --David -Original Message- From: Dick Hardt [mailto:[EMAIL PROTECTED] Sent: Friday, April 06, 2007 1:07 PM To: Recordon, David Cc: OpenID specs list; Paul Trevithick; Mark Wahl Subject: Re: PROPOSAL schema.openid.net for AX (and other extensions) If there was something out there already, I would propose we used it. There is not. Just like the SAML crowd has accused the OpenID crowd of reinventing an identity protocol (AKA reinventing the wheel) -- the AX proposal has some unique concepts that people like Paul and Mark think are quite innovative. Other schemas don't support them. I have cc'ed Paul and Mark in case they can point to some new work that we can take advantage of today. Other responses inserted: On 6-Apr-07, at 11:49 AM, Recordon, David wrote: As I've stated in the past, I have no problem with using schema.openid.net to define attributes such as the authoritative URI for an OpenID URL, i-name, etc. I do have a problem with using this namespace to define an attribute such as a First Name. I do not feel that this community should be dealing with all of the issues such as First Name vs. Given Name, as that is not where the expertise is, let alone it has been done in the past. I also strongly believe that due to the number of other definitions of these attributes, either we as a community should decide to use one of them or work with a project such as ID Schemas to create a set of URIs not tied to the OpenID project that solves both our needs and the needs of others. I do not particularly care where this work would happen and as I've said in the past, I'd be fine with someone just buying a domain to do the work to preserve the speed for getting this bootstrapped while not tying it to OpenID. If really don't care, then you should not care if it is happening in OpenID then. First Name: - http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname This URL could be used. To date they have not made these self describing. Who knows what this is? The AX proposal is to make the URLs describing. This makes it easier for programmers to know what it is they are working with. - http://xmlns.com/foaf/0.1/firstName - http://xmlns.com/foaf/0.1/givenname Both of these are elements in a larger XML document. This is not the model of AX. - http://en.wikipedia.org/wiki/First_name While intriguing to have wikiality define terms, this is not practical since the definition needs to be static or code will break I'm sure if Paul Trevithick or Mark Whal join this conversation they'd be able to highlight even more URI definitions of a First Name than I was in a cursory search. This also isn't
Re: Re[2]: Server-to-server channel
On 4-Apr-07, at 8:59 PM, Chris Drake wrote: Thursday, April 5, 2007, 5:43:02 AM, you wrote: [snip] DO How these keys are handled internally could be left to the DO consumer or RP. [snip] This sounds like another *strong* use-case for updating the OpenID protocol to allow transactions to take place when the user is not present. I am not likely to be present when people relying upon my certificates choose to verify signatures, check for revocation, or attempt to encrypt stuff destined for me. There needs to be a way for the RP to contact my OP and get access to my information (eg: my current public key and revocation list) - by my explicit prior consent of course. Having your public key discoverable at your URL makes lots of sense, it is by its very nature, public. I would not consider fetching the public key to be a transaction though. -- Dick ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Moving AX Forward (WAS RE: SREG namespace URI rollback)
Doing the work in the ID Schemas project was a good idea 3 months ago and 6 months ago. So far not much has happened there. I agree that having several groups do the same thing is undesirable, but we do need to get moving. We need URIs for moving attributes today. We can wait for the metadata [1] to get defined, and the members of the ID Schema group are the right people for that.[2] While it is desirable that there is only one definition of an attribute, and some people may define the same attribute through lack of knowledge of each other. The attribute meta data model proposed[1] allows for one definition to reference another definition to consolidate attribute definitions. Additionally, getting everyone to agree on the syntax will be hard. The model allows different people to define attributes in different ways. The market will decide then what works best through use. btw: Currently there is no consistent, extensible, self describing attribute schema system out there that I know of, or anyone in the ID Schema Working group knows of. We can start to define attributes in the openid.net namespace and then reference more authorative URIs when they exist. This would let the OpenID community define the immediately required attributes for people to implement and deploy AX, which will likely increase awareness [1] http://openid.net/specs/identity-attribute-metadata-1_0-01.html [2] Of course we have all the issues of IPR etc. at the ID Schema working group since it would be unclear what organization would be managing that spec. Over here in the OpenID community we are working to resolve that, so perhaps the ID Schema people could participate in a list hosted at openid.net? -- Dick On 4-Apr-07, at 10:27 PM, Drummond Reed wrote: +1 to defining attribute identifier URIs/XRIs in the Identity Commons ID Schemas project. =Drummond -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Recordon, David Sent: Wednesday, April 04, 2007 1:16 PM To: Johnny Bufu Cc: OpenID specs list Subject: RE: Moving AX Forward (WAS RE: SREG namespace URI rollback) Johnny, I see a lot of, at least my initial confusion, coming from there being multiple documents. This is why I urge merging the transport and metadata since the reality is they currently are only being used with each other. As the metadata document doesn't actually define a new format, rather references existing formats, I am unsure why it cannot just be a section in the transport document. It is understood that you must use the metadata format for the schema URLs in the transport, so the two documents really are coupled to begin with. I agree that you need to bootstrap a set of attributes for people using AX. As I have done so in the past, I'd encourage this work happen within the ID Schemas project (http://idschemas.idcommons.net/) versus defining First Name yet again for openid.net. I have no problem with the spec listing a set of schema URLs, I just strongly feel that anything non-OpenID specific should be hosted and defined elsewhere since so many people have already done it. I do understand the need for the schema URL hosting the metadata document, which is why I am advocating this work be done as part of the ID Schemas project to provide this flexibility. --David -Original Message- From: Johnny Bufu [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 04, 2007 12:39 PM To: Recordon, David Cc: Dick Hardt; OpenID specs list Subject: Re: Moving AX Forward (WAS RE: SREG namespace URI rollback) On 4-Apr-07, at 12:18 PM, Recordon, David wrote: One thing that I do think would be worthwhile in smoothing more of this SREG/AX confusion would be adding SREG support to Sxip's OpenID libraries. This is on the todo list, and judging by the interest showed by some contributors could happen any day now. Any thoughts on spec consolidation I think I'd propose the following: - Remove http://openid.net/specs/openid-attribute- types-1_0-02.html (I do not believe OpenID should define its own schema elements for things like First Name which are not specific to OpenID, defining a URL for an OpenID enabled URL for example I think would be fine on OpenID.net) I understand that point of view and we were looking into determining what would be the best place where this spec could live. However, since the AX's adoption will depend (at least in the beginning, before the metadata and automatic acquisition mechanisms are finalized) on the participants using the same names for the attributes they transfer. From this point of view, I believe AX could use openid.net's recommendation (if endorsement is too much) to use a set of names / URIs for the most commonly transfered attributes. (Kind of like what made SREG successful -- having the spec provide / something/ for a jump-start). - Merge http
Re: Moving AX Forward (WAS RE: SREG namespace URI rollback)
On 4-Apr-07, at 1:16 PM, Recordon, David wrote: Johnny, I see a lot of, at least my initial confusion, coming from there being multiple documents. This is why I urge merging the transport and metadata since the reality is they currently are only being used with each other. As the metadata document doesn't actually define a new format, rather references existing formats, I am unsure why it cannot just be a section in the transport document. It is understood that you must use the metadata format for the schema URLs in the transport, so the two documents really are coupled to begin with. Actually it is describing a document format, and it could easily be used by other groups as evidenced by references from people in the ID Schemas group. I agree that you need to bootstrap a set of attributes for people using AX. As I have done so in the past, I'd encourage this work happen within the ID Schemas project (http://idschemas.idcommons.net/) versus defining First Name yet again for openid.net. I have no problem with the spec listing a set of schema URLs, I just strongly feel that anything non-OpenID specific should be hosted and defined elsewhere since so many people have already done it. I do understand the need for the schema URL hosting the metadata document, which is why I am advocating this work be done as part of the ID Schemas project to provide this flexibility. see my response to Drummond ... We defined a set of attributes 6 months ago under schema.openid.net. I think we have let other groups have time to do something, I'd like to get on with building and deploying stuff. -- Dick ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Attribute Exchange 1.0 svn revision 295 review
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)
On 5-Apr-07, at 9:06 AM, Recordon, David wrote: Actually it is describing a document format, and it could easily be used by other groups as evidenced by references from people in the ID Schemas group. I agree that it could be, but is anyone? It leaves the option open. I love shooting beyond the 80% to get the remaining 20%, but if that is just a pipe dream then I have a hard time seeing why the documents need to be separate and thus more complex. An RP does not need to worry about the metadata, so it is much easier for an RP to implement if they don't need to look at the other document. I don't think this is really that important of a point given all the other things we need to do. People are doing to do things different then you would, but get the same result -- is that ok? We defined a set of attributes 6 months ago under schema.openid.net. So Dick, this is part of my problem with AX. Sxip has defined a set of attributes and never gained consensus on this list that that is the right thing to do. We wanted to publish them on the website so that other people could look at them, but you did not want to do that, and you control the domain. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Moving AX Forward (WAS RE: SREG namespace URI rollback)
If you would let us put the attributes on the website, then other people could see them and comment on them. On 5-Apr-07, at 9:02 AM, Recordon, David wrote: I guess I don't see why blaming the ID Schemas project for not much happening is a good excuse for not doing it there. Blame? ... just stating a fact. People who care will either have to drive this work within the OpenID project or the ID Schemas project; I fail to see how the effort required in each differs greatly. In some senses, I think if people gather as part of the ID Schemas project and try to move this work forward, it will actually be more successful than trying to do it here. People have not gathered and done work on the ID Schemas project to date. People are now gathering on the OpenID list around AX -- so let's use that momentum. I stated several reasons why it makes sense to do it here. Nothing done by OpenID in the past has intrinsically been easy which is why I continue to think that something being hard is not a valid reason to not do the right technical/social thing. I know that these two communities can work together, but the onus is on the OpenID AX side to make this conversation successful and drive progress. Oh, so if we add MORE people to the mix it will be easier!!! :-) ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Promoting OpenID
On 2-Apr-07, at 8:15 AM, McGovern, James F ((HTSC, IT)) wrote: Is anyone here working with vendors in the ERP, CRM, ECM, BPM or VRM spaces such that user-centric identity is built into their product? We are working with salesforce.com ... ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Attribute Exchange pre-draft 5
On 3-Apr-07, at 3:32 AM, Josh Hoyt wrote: If I understand correctly, the response to a request for an attribute with count.x=1 is different from the response for a request with no count specified, even though the meaning is the same. (namespacing left off for clarity) Request: .type.a=http://example.com/a .count.a=1 .type.b=http://example.com/b Response: .type.a=http://example.com/a .count.a=1 .value.a.1=avalue .type.b=http://example.com/b .value.b=bvalue Even though the request for a and b have equivalent meaning (send zero or one values for this attribute) the response MUST encode them in different ways. I think this is ugly, because the detail of the way that the attribute was requested has to be preserved in the code, to ensure that the response can be encoded correctly. (it's not sufficient to just default the count to one if it's not specified) Is there a reason that it's specified this way? I'd prefer if there was only one way to do it. Good point. Either .count. has to be more then 1 in a request so that there is only one way to do it, or the response could be in either form where .count.=1 to be consistent with the request being able to be in either form. Also, can the count be zero in the response? it seems like that's OK, and if it is, it'd address my concern about overloading zero-length strings to mean no value. Another good point. I agree it should be able to be zero. -- Dick ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Server-to-server channel
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
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
On 3-Apr-07, at 3:05 PM, Anders Feder wrote: Dick Hardt wrote: There are two common client server design patterns. Request / Response and Publish / Subscribe. I see - I was not aware that the latter model was so well- understood in the client/server paradigm. The RP has what ever the user last gave the RP. If the user is involved in the transaction, the RP may ask the user for up to date information. Note that your concern is constrained to situations where the user is not involved. It is, but will automated transactions not make up a significant portion of the communications on the service-oriented Web? * If an OP fails to update an attribute, the RP will never know - no fall-backs can be implemented. When the data changes, the user then decides if the RP gets the data. If the user did not want the RP to get, well that is what the user decided. This is user centric after all. I see the merits of user-centricism, but what happens if a user do want an RP to receive an update but the RP is unavailable? The OP can try again later. The reverse would need to be true if the OP was not available when the RP wanted to get the data. * When updating, the OP impose a previous address structure upon the Web, regardless of how it is actually organized now. The converse would be the RP imposes an address structure on the OP on where to get the updated data. And rightfully so, because the user selects his OP based on his trust that its address structure will not change - this is the key principle in OpenID. The user can change OPs if they are using delegation. Well, the OP would be responsible for responding to all the myriad useless RP requests for updated data if a pull model. Good point :) In most cases you are probably right, but one can imagine attributes, especially in futuristic scenarios, which are almost inherently 'pull' (like GPS data) such that translating them into 'pushes' are immensely ineffective. But I guess 'push' is per- attribute optional, in that case? Who has access to my GPS data is something I will want to tightly control! information to RP's it has no direct interest in. A malicious RP may even exploit this storage space for own purposes. * The OP must donate storage space to support the distribution of The alternative would be the OP would need to donate storage to support which RPs are allowed to ask for data. Only if the user actually wish to restrict access - and the RP would not have access to this storage. I think we all learned the negative aspects of having our data publicly searchable with email and spam. The FOAF camp was rolling along with the Pull model until they realized the issues around access control of the data. Anyway, I'm convinced you have thought it through. Pull relates to push as quantum mechanics relates to relativistic physics - but very often quantum mechanics is overkill. Not sure I follow the analogy. Push is actually much simpler then Pull for any kind of sensitive data, which is most of the useful attribute data. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Web Access Management
Ping demoed OpenID technology at RSA. I hear Novell and IBM are looking at supporting OpenID. Microsoft has said they will in future products. Oracle and CA are following OpenID. So, yes. :-) On 2-Apr-07, at 8:21 AM, McGovern, James F ((HTSC, IT)) wrote: Unlike blog sites and Internet startups, many large enteprises have purchased Web Access Management products such as Tivoli Access Manager, Netegrity Siteminder, etc where authentication doesn't occur by embedding code into the application. Is anyone directly working with any of the vendors in this space to promote OpenID? ** *** This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies. ** *** ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: SREG namespace URI rollback
I can see an OP thinking that AX is a big step, but have a hard time seeing it to be that big for an RP (once there are libraries that support AX) ... and it is really not that much more to do AX over SREG for an RP. Where you thinking OP or RP David? -- Dick On 3-Apr-07, at 12:17 PM, Recordon, David wrote: I see there being a gap between SREG and AX with nothing bridging it. IMHO, AX takes too large of a step for people to use it if they just want a few more SREG fields. I think we need something which does nothing more than provide a way to extend SREG and that will solve the majority of problems today. --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Josh Hoyt Sent: Monday, April 02, 2007 7:16 PM To: Recordon, David Cc: Johnny Bufu; OpenID specs list Subject: Re: SREG namespace URI rollback On 4/2/07, Recordon, David [EMAIL PROTECTED] wrote: Sure, though I think there has also been a desire to do a bit of an actual rev to SREG to be more of a 1.1 version in terms of either explicitly supporting additional fields (such as avatar) or allowing field names to be URIs themselves versus a hard-coded list of properties. -1 SREG works because it's so dead simple. Attribute exchange is not much more complicated, and it lets you specifiy field names with URIs *and* allows you to define any attributes you see fit. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Features for Future Versions
On 2-Apr-07, at 8:09 AM, McGovern, James F ((HTSC, IT)) wrote: I originally joined this list with the hopes of injecting support for relationships, authorization and attestation into the specification but have been somewhat disappointed. I do have the following questions? 1. Will OpenID avoid incorporating features where identity selectors such as Cardspace don't support the functionality? 2. Will OpenID always constrain itself to areas where traditional PKI vendors have played (authentication) and avoid areas where PKI can't tread (authorization)? Hi James Authentication and authorization are somewhat overloaded words and different people mean different things by them. I recall you sending out a link to a set of requirements you had helped create. The dynamics of this mailing list tend to support concise use case discussion rather delve into large documents. A concise use case of what you mean by Authorization may prove useful to guide the discussion and work. -- Dick ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Attribute Exchange pre-draft 5
On 2-Apr-07, at 2:41 PM, Rowan Kerr wrote: On 2-Apr-07, at 5:27 PM, Josh Hoyt wrote: I'm thinking about differentiating between an attribute that's not available and an attribute that *is* available, but its value is . I. e. difference between a null pointer, and a pointer to an empty string. That was part of why I had the idea of adding one or two extra response values... to know whether a user released the attribute (and whether it was supported by the OP). Personally, I don't see that much value to the RP in the RP getting additional information that the data was available but not released, and unnecessary disclosure on behalf of the user. By looking at the namespace RDFs for the OP as you suggested, the RP should be able to decide whether the value is supported by the OP, then if it's blank AND supported, then the only thing the RP can't be sure about is whether or not the user released it. Note that AX enables an OP to dynamically support new attributes on the fly -- and publishing ALL available attributes for a user would be a privacy problem. If the RP really needs a value, they can prompt the user for it after getting the AX response and it doesn't really matter whether the OP supports it or not. (Unless you're going to maybe try and Store it back to the OP later on). But prompting users twice for the same value (for lack of any way to know the cause of a blank value) might be an annoying experience. The RP has given the OP a hint that the value is required. If the user has instructed their OP to NOT give the value, then the RP can then decide what to do, and the user will likely expect to get prompted again. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Version 2.0 soon final?
On 26-Mar-07, at 12:22 PM, Josh Hoyt wrote: On 3/20/07, Granqvist, Hans [EMAIL PROTECTED] wrote: OpenID 2.0 has been cooking for quite a while. When will 2.0 be FCS? What does FCS [1] mean? Josh 1. http://en.wikipedia.org/wiki/FCS Future Combat Systems? http://en.wikipedia.org/wiki/Future_Combat_Systems ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Extensions key prefix
On 13-Mar-07, at 6:23 PM, Drummond Reed wrote: Rowan, If I understand you correctly here, what you are saying is that openid.ns.* prefixes work almost identically to XML namespace (xmlns) prefixes, i.e.: that is where the idea came from :-) * the prefix is never globally defined by dynamically defined on a per-instance basis ... never globally defined *but* is dynamically defined ... * thus you don't know what the prefix is in a specific OpenID message until you parse the message. correct -- and good point to call it out as clearly it is not obvious to people -- thanks! -- Dick ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Proposal: An anti-phishing compromise
I chatted with Avery about this today. URIs for specific auth methods as well as ones for general seems to be the flexible approach. Per Kim's laws, the method of auth may not be needed, so is extra disclosure On 8-Feb-07, at 11:38 PM, Recordon, David wrote: Maybe laws are meant to be broken. I don't see why a RP knowing that I used a token as a second factor is a bad thing. If nothing else, the technology should support the OP providing that information and the OP's implementation can let me as the user decide if I want to. Just like the trust request, it isn't mandated by the spec but every worthwhile OP does it. My $0.02. --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dick Hardt Sent: Sunday, February 04, 2007 11:42 PM To: Granqvist, Hans Cc: OpenID specs list Subject: Re: Proposal: An anti-phishing compromise On 1-Feb-07, at 2:36 PM, Granqvist, Hans wrote: Add a single, required, boolean field to the authentication response that specifies whether or not the method the OP used to authenticate the user is phishable. The specification will have to provide guidelines on what properties an authentication mechanism needs to have in order to be non-phishable. The field is just meant to indicate that the authentication mechanism that was used is not a standard secret entered into a Web form. The receiver should decide what is 'non-phishable', not the sender, so it would be better if the OP just states what mechanism was used, perhaps. Per Kim's laws, how I authenticate to my OP is none of the RP's business. That I authenticated in a phishing resistant manner is. ie. we want the OP to make the statement that it followed certain anti-phishing guidelines. There is no certainty that the OP followed them, but the RP and user have recourse against an OP if the OP stated that it did follow the anti-phishing guidelines. -- Dick ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Proposal: An anti-phishing compromise
On 1-Feb-07, at 2:36 PM, Granqvist, Hans wrote: Add a single, required, boolean field to the authentication response that specifies whether or not the method the OP used to authenticate the user is phishable. The specification will have to provide guidelines on what properties an authentication mechanism needs to have in order to be non-phishable. The field is just meant to indicate that the authentication mechanism that was used is not a standard secret entered into a Web form. The receiver should decide what is 'non-phishable', not the sender, so it would be better if the OP just states what mechanism was used, perhaps. Per Kim's laws, how I authenticate to my OP is none of the RP's business. That I authenticated in a phishing resistant manner is. ie. we want the OP to make the statement that it followed certain anti-phishing guidelines. There is no certainty that the OP followed them, but the RP and user have recourse against an OP if the OP stated that it did follow the anti-phishing guidelines. -- Dick ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Federated Authorization
On 25-Jan-07, at 1:36 PM, McGovern, James F ((HTSC, IT)) wrote: Modify your scenario as follows: - Tthe College of Physicians and Surgeons says she is a surgeon and is board certified for X number of procedures - A particular hospital says she is part of their team. Likewise, they also know that she plays different roles at other hospitals. Minimally we want to know when her admission priveleges expire - The university says she is part of their faculty and teachs in both the business school and engineering school. - the government says she is the business owner of her surgical practice and also serves in a board capacity on other boards Hopefully we can develop specifications which go deeper than just matching/correlation of identity and attribute. Hi James I don't follow your last comment. Would you elaborate? -- Dick___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: 2.0 Spec Questions
On 21-Jan-07, at 4:48 PM, James McGovern wrote: Several questions after reading the 2.0 spec - draft 11. 1. The definition of realm if I am reading it correctly could be problematic in large enterprises. For example, if one were using a web access management product, they would have the ability to define a realm in terms of a listing of discrete hosts that may or may not fit a URL pattern matching approach. For example, I could have a demographic called consumers who could access hosts such as http://myconsumer.example.com , http://printstatements.example.com, http://paybills.example.com Likewise another demographic called Business Partner may have a different set of hosts they can interact with. The motivation of the realm is to deal with web sites where there are many host names, but really one site -- LiveJournal being the motivating use case, as well as being where OpenID got its start. Each blog has a separate hostname: dick.livejournal.com brad.livejournal.com Since different blogs have different hostnames, but a user thinks of them all as being lLiveJournal, so being able to have a realm of: *.livejournal.com 2. In terms of checking the nonce, can we recommend that a deployment practice should be to use the NTP protocol and point to clocks of a certain stratum? Likewise, would it be a good idea if an association could indicate how much skew it would accept before rejecting? The date-time stamp in the nonce is really to assist the RP in knowing that it can discard a message if it is older then a x period rather then having to hold every nonce received. I don't know how much skew happens out in the wild these days, but perhaps we could get an idea of what that is and then recommend how long the RP should keep a nonce before discarding? 3. In terms of an extension, should an OP be able to indicate when reauth may be required so the user doesn't assume that if they authenticate once they are always good? AuthN is for the benefit of the RP. While one view might be that the OP should be able to dictate how long the AuthN is good for, once used, it is really the RP that is determining if it is the same user. I think the more important consideration is the RP wanting to get the OP to do AuthN for the user instead of using a cached AuthN. I wanted to put it in the spec, but the decision was that it was better in an extension. 4. Some portions of the spec are heavily coupled to PKI. How should growing users of IBE think of this? Besides recommending sites use TLS, I don't see the PKI coupling you are referring to. Would you elaborate? ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: [OpenID] Announcing OpenID Authentication 2.0 - Implementor's Draft 11
On 19-Jan-07, at 6:19 AM, Ben Laurie wrote: Still totally unhappy about the phishing issues, which I blogged about here: http://www.links.org/?p=187 There are numerous ways of solving this. Several standard methods can solve it. It is a relationship between the user and the OP and the RP is not party, so I don't think it belongs in the OpenID Authentication specification. That does not mean it is not important, just that *this* spec is not the right place. -- Dick ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
DRAFT 11 - FINAL?
Hey List To deal with the recent security concern postings about OpenID, language was added to clarify a secure channel is needed between the OP and the end-user's machine. Are there any more issues with this specification: http://openid.net/specs/openid-authentication-2_0-11.html Can we make this final? -- Dick ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Federated Authorization
Hi James As Phillip states, SAML can be used to represent the assertion. Interesting that you mention a Doctor example. A use case that we are working on uses a Surgeon (Sally) who needs to prove: - Tthe College of Physicians and Surgeons says she is a surgeon - A particular hospital says she is part of their team - The university says she is part of their faculty - the government says she is the business owner of her surgical practice With OpenID, each of these authorities could make a claim about Sally's OpenID. This could be expressed as a SAML assertion. When accessing a resource that requires one of Sally's verified attributes, Sally (using her OP) proves she is a specific OpenID Idenitifier and also provides the SAML assertion(s) that prove that identifier has been verified to belong to a surgeon, team member, faculty member, business owner. We have created an example for something anyone on the net can have verified, their email address. I'll post separately about that. -- Dick On 18-Jan-07, at 8:51 AM, McGovern, James F ((HTSC, IT)) wrote: I would love to see folks hear that also blog not only continue to discuss federated identity but also consider of the course of several additional postings also talk about the need for federated authorization. Consider an example where a Doctor in a hospital is having an electronic interaction with a healthcare insurance provider. The hospital should be the identity provider while the entity that licensed the Doctor for given sets of practices should be responsible for certain forms of authorization. If we only talk about identity without authorization, the conversation will result in lots of great software where folks who create them won't make any money since consumer-centric interactions have volume without corresponding revenue. ** *** This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies. ** *** ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: DRAFT 11 - FINAL?
OK -- would it be possible to keep the list apprised of the progress and post the issue and resolution once you are done this afternoon? -- Dick On 18-Jan-07, at 3:55 PM, Recordon, David wrote: Considering draft 11 hasn't been published yet, I don't see how we can make it final at this point. In addition, the file you link to is a few patches old. While I appreciate your enthusiasm, Josh, Johnny, and I do have a process to this madness. I know you know that we're really close, there is one remaining issue Josh, Drummond, and I are tackling this afternoon, and then we'll publish draft 11. Thanks, --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dick Hardt Sent: Thursday, January 18, 2007 3:45 PM To: specs@openid.net Subject: DRAFT 11 - FINAL? Hey List To deal with the recent security concern postings about OpenID, language was added to clarify a secure channel is needed between the OP and the end-user's machine. Are there any more issues with this specification: http://openid.net/specs/openid-authentication-2_0-11.html Can we make this final? -- Dick ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Announcing OpenID Authentication 2.0 - Implementor's Draft 11
Great job David, Johnny and Josh! -- Dick On 18-Jan-07, at 7:35 PM, Recordon, David wrote: So with great pleasure I get to announce the culmination of about nine months of work between the OpenID, XRI, Sxip, and LID communities in the drafting of OpenID Authentication 2.0. This evening the editors have published the final draft of the spec, which we now feel is in a solid state for public implementations. There are already implementations in various languages (http://svn.apache.org/repos/asf/incubator/heraldry/libraries/, http://code.google.com/p/openid4java/, http://code.google.com/p/openid4perl/) supporting this spec and more will emerge over the next few weeks. There will be another draft of the spec before it is considered final, though unless unforeseen implementation problems emerge these changes will be further wordsmithing and cleanup. http://openid.net/specs/openid-authentication-2_0-11.html (dated today) Cool? Cool! --David ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Announcing OpenID Authentication 2.0 - Implementor's Draft 11
David A couple questions: 1) Would you like to set a deadline for final comments? Perhaps a week? 2) What is the approval process now? Is it still as posted at: http://openid.net/specs.bml Currently, the collective authors of OpenID Authentication (David Recordon, Josh Hoyt, Dick Hardt, and Brad Fitzpatrick) oversee this process and make the final determination of when a proposal has matured. -- Dick On 18-Jan-07, at 7:35 PM, Recordon, David wrote: So with great pleasure I get to announce the culmination of about nine months of work between the OpenID, XRI, Sxip, and LID communities in the drafting of OpenID Authentication 2.0. This evening the editors have published the final draft of the spec, which we now feel is in a solid state for public implementations. There are already implementations in various languages (http://svn.apache.org/repos/asf/incubator/heraldry/libraries/, http://code.google.com/p/openid4java/, http://code.google.com/p/openid4perl/) supporting this spec and more will emerge over the next few weeks. There will be another draft of the spec before it is considered final, though unless unforeseen implementation problems emerge these changes will be further wordsmithing and cleanup. http://openid.net/specs/openid-authentication-2_0-11.html (dated today) Cool? Cool! --David ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Announcing OpenID Authentication 2.0 - Implementor's Draft 11
Hi Daniel The OpenID4java code is up to date to DRAFT 11, and also has support for the OpenID Attribute Exchange draft. (Sxip volunteered to build the OpenID Java libraries, and our preference was to use code.google.com for the repository) -- Dick On 18-Jan-07, at 11:52 PM, Daniel E. Renfer wrote: I'm a little confused. You list Heraldry as being OpenID Auth 2.0 enabled, but looking at the SVN logs it seems like only the python library has been seeing activity. (And all of that in a flood of commits) Is there any word on when we will see the rest of the libraries brought up to spec? I'm looking for Java support in particular. Will there be many major changes upgrading from the current code to the Auth2.0 code? I want to code my site (still in private development) to be 2.0 friendly from the get go, but I'm not sure if I should be using the openid4java code or wait for Heraldry to be updated. -- Daniel E. Renfer http://kronkltd.net/ On 1/18/07, Recordon, David [EMAIL PROTECTED] wrote: So with great pleasure I get to announce the culmination of about nine months of work between the OpenID, XRI, Sxip, and LID communities in the drafting of OpenID Authentication 2.0. This evening the editors have published the final draft of the spec, which we now feel is in a solid state for public implementations. There are already implementations in various languages (http://svn.apache.org/repos/asf/incubator/heraldry/libraries/, http://code.google.com/p/openid4java/, http://code.google.com/p/openid4perl/) supporting this spec and more will emerge over the next few weeks. There will be another draft of the spec before it is considered final, though unless unforeseen implementation problems emerge these changes will be further wordsmithing and cleanup. http://openid.net/specs/openid-authentication-2_0-11.html (dated today) Cool? Cool! --David ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Question on Conferences and the Marketing of OpenID
On 8-Jan-07, at 7:01 AM, James McGovern wrote: I learned of OpenID because I ran across it while blogging. Otherwise, in context of my day job working for a Fortune 100 enterprise whose primary business model isn't technology otherwise would have never heard of it. While this list is to discuss specifications, this begs the question of should we create specifications around how to get the word out better to all of my industry peers. Noticed that folks from Verisign were key players in the creation of this spec, yet it is not prominently mentioned on their web site. If you know to search for it, it still only returns two results. What do we need to do to get Verisign and the other large guys (small guys are covered) to show a little more respect towards OpenID in terms of their own web site? Good question for VeriSign! I ran across The : Authentication and Online Trust Alliance and their upcoming conference (http://www.aotalliance.org/summit2007/) and noted that no one is talking about stuff in our space. Does anyone have a list of all planned 2007 conferences where OpenID should be discussed? I don't have ALL conferences, but here are some that I known of: Catalyst, Digital ID World, Gartner IdM. Additionally, there are the Web 2.0 and O'Reilly Emerging tech conferences. I am speaking at a couple of CERT conferences and the W3C conference as well as a couple European IdM conferences. Also curious if anyone has been pushing the industry analyst crowd to provide coverage? If not, I will need lots of folks to start submitting inquiries to Gartner, Forrester and the Burton Group to get them to pay attention. I have briefed Gartner, Forrester and the Burton Group on OpenID and the user-centric model. User-centric identity was discussed in several presentations at the last Catalyst conference. At that time, SXIP/DIX and OpenID had not converged and DIX had more prominence. -- Dick ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Business Scenarios
We are working on a citizen-centric solution for regional set of public sector organizations. Most of the major IdM vendors are involved, but no white papers have been published at this time. -- Dick On 10-Jan-07, at 8:42 AM, McGovern, James F ((HTSC, IT)) wrote: I am looking for any generic whitepapers targeted at any vertical that outline a business scenario (not the usual consumer- orientation) where user-centric identity has either been deployed or at least discussed. Also would love to know of situations in which user-centric identity displaced PKI based implementations. If something exists in this space but hasn't been written up, maybe I could task several industry analysts to provide coverage. ** *** This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies. ** *** ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Attribute Exchange Schema site
Hi Rowan We will be releasing a tweaked version of the Attribute Exchange spec tomorrow. Adds a simple way to support requested and receiving multiple values for the same type. The old properties list is here: (there is a link to archives at the bottom of the specs page on OpenID.net) http://openid.net/specs/openid-attribute-properties-list-1_0-01.html We now a document for each property that has RDF so that it is both programatically readable and human readable. Just need to decide the domain to put them! The Attribute Type model is such that anyone with a domain can define new attributes. No need for central control. We created a set of what we thought were common attributes, but that does not mean anyone has to use them. Glad to hear someone is spending more time implementing that discussing. ;-) -- Dick On 4-Jan-07, at 12:49 PM, Rowan Kerr wrote: On 1/3/07, Dick Hardt [EMAIL PROTECTED] wrote: Our proposal was to have the schemas for OpenID hosted at schema.openid.net. Some people expressed concerns about having them be on openid.net. Do you have any suggestions? Anyone else have an opinion? Does anyone care? ;-) Being part of the OpenID specs, it would make sense to me to have them hosted under the OpenID domain. (While a centralized, shared list of properties would be great in the long run, who knows how long it could take to get agreement from something like idcommons). Really, I don't particularly mind if they're even hosted anywhere at the moment as long as the list of properties is well defined. We've implemented a OP at my.standardradio.com that supports OpenID 2 and the Draft 1 version of AX properties, and I'm in the middle of writing documentation for our 3rd party clients on how to work with our site so I was hoping to be able to update it to the latest version of the spec before sending out documentation that is already behind the times. Failing a solid list of AX Draft 2 properties, is the Draft 1 documentation still online somewhere? There is a schema effort over at http://idschemas.idcommons.net/ -- but discussion over there has been minimal to date, but perhaps this can jump start things ... I'll check that out, I remember when it was announced but never followed up on how any of that was progressing. btw: nice to see a fellow Canuck on the list! Glad to be here! I've been on for a while but not had cause to jump into the discussions much. Too busy implementing... :) -Rowan ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
OpenID Signed Assertions 1.0 - Draft 1
tions of that document were re-used for this one. TOC 12. References TOC 12.1.Normative References [OASIS.saml-conformance-2.0-os] Mishra, P., Philpott, R., and E. Maler, Conformance Requirements for the Security Assertion Markup Language (SAML) V2.0, OASIS Standardsaml-conformance-2.0-os, March2005. [OASIS.saml-core-2.0-os] Cantor, S., Kemp, J., Philpott, R., and E. Maler, Assertions and Protocol for the OASIS Security Assertion Markup Language (SAML) V2.0, OASIS Standardsaml-core-2.0-os, March2005. [OASIS.saml-profiles-2.0-os] Hughes, J., Cantor, S., Hodges, J., Hirsch, F., Mishra, P., Philpott, R., and E. Maler, Profiles for the OASIS Security Assertion Markup Language (SAML) V2.0, OASIS StandardOASIS.saml-profiles-2.0-os, March2005. [OpenID.attribute-exchange-1.0] Hardt, D., OpenID Attribute Exchange 1.0 - Draft 03, November2006 (TXT, HTML). [OpenID.authentication-2.0] Recordon, D., Hoyt, J., Fitzpatrick, B., and D. Hardt, OpenID Authentication 2.0 - Draft 10, August2006 (TXT, HTML). [RFC2119] Bradner, S., Key words for use in RFCs to Indicate Requirement Levels, BCP14, RFC2119, March1997 (TXT, HTML, XML). [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, RFC3280, April2002. [RFC3548] Josefsson, S., The Base16, Base32, and Base64 Data Encodings, RFC3548, July2003. [W3C.REC-xmldsig-core-20020212] Solo, D., Eastlake, D., and J. Reagle, XML-Signature Syntax and Processing, W3C Recommendationhttp://www.w3.org/TR/2002/REC-xmldsig-core-20020212, February2002. TOC 12.2.Informative References [OASIS.saml-glossary-2.0-os] Hodges, J., Philpott, R., and E. Maler, Glossary for the Security Assertion Markup Language (SAML) V2.0, OASIS Standardsaml-glossary-2.0-os, March2005. [OpenID.attribute-types-1.0] Hardt, D., OpenID Attribute Types - Draft 02, November2006 (TXT, HTML). TOC Author's Address Dick Hardt Sxip Identity 798 Beatty Street Vancouver, BC V6B 2M1 CA Email: [EMAIL PROTECTED] URI: http://sxip.com/ ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OpenID Authentication 2.0 Pre-Draft 11 (Take 5)
On 25-Nov-06, at 12:10 AM, Recordon, David wrote: Decent number of changes to help clean-up the draft from what I posted on the 19th. Getting close with only a few more things left on the punch list! Thanks for posting David. What do we have left on the list? -- Dick ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Attribute Exchange, Attribute Types and Attribute Metadata
Below is a summary of draft specifications for OpenIDAttribute Exchange, Attribute Types and Attribute Metadata. I will check them into SVN real-soon-now and hopefully David will have them linked off the spec site. HTML versions will be posted as separate emails for those in the US unable to fall asleep eating too much turkey! Additionally, if anyone is interested in being a co-editor, please let me know! -- Dick +++ OpenID Attribute Exchange is an OpenID service for exchanging identity information between endpoints. Messages for retrieval and storage of identity information are provided. Attribute types for a variety of different identity properties have been defined, and additional types may be defined by any interested parties. The creation of new attributes in the openid.net name space is outlined in the new OpenID Attribute Types document, and involves submitting proposals for new types to a [EMAIL PROTECTED] mailing list that we hope to create. Although it means yet another OpenID mailing list, it will confine type related traffic away from more general discussion on the main specification list. Note that this process only applies to attributes defined in the schema.openid.net name space, and users are free to define their own attribute types in other name spaces. The previous list of attribute types has been turned into a set of metadata documents describing each type, which will be posted to a new web server at schema.openid.net. A new document, Identity Attribute Metadata has been created outlining a proposed metadata format for attribute types. The idea behind the metadata format is that each attribute type identifier is a URL that resolves to the metadata describing the type. This way, attribute types may be requested without their format or other information about them being hard coded in OP or RP applications. The metadata includes localized labels and text descriptions, data format descriptions, and information on authority, acquisition and cross referencing. The type information is encoded in XML for easy parsing, and is supplied with an XSL style sheet for a human readable translation. Document Changes The third draft of the Attribute Exchange document incorporates a series of changes based on community input and the progress of the OpenID Authentication 2.0 draft document. Chief among these changes has been an update to the way the fetch response message, the parameters of which now are incorporated into the openid name space. Other minor changes were made to clarify some points and to incorporate suggestions made by the implementation team: * Attribute name changed to attribute type identifier * Updated references to Attribute Types document * Added multiple alias support to required and if_available parameters * Extended examples to include multiple aliases * Additional documentation of the fetch response message * Additional documentation of the store response messages The Attribute Properties document, with the list of attribute properties, has been eliminated in favour of an Attribute Types document that outlines the process to define new types in the schema.openid.net name space. This will encourage more community participation in defining new types. Comments and suggestions on how to can improve these specifications are always welcome! ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
OpenID Attribute Types Draft 2
type will be moved into the non-experimental name space and the [EMAIL PROTECTED] list notified. The approval stage of the process is deliberately vague; the idea being that a more detailed process will emerge as more interested parties take part. In any case, approval should be the default action if there is no vocal disapproval and the proposed type is not a duplicate of an existing type. TOC 4.2. New Attribute Data Format Process New attribute data format types are proposed and approved in a similar manner to attribute types themselves. The proposed type is sent to the list expressed in XML Schema ([W3C.RECxmlschema220041028] (Biron, P. and A. Malhotra, XML Schema Part 2: Datatypes Second Edition, October2004.)) format as outlined in [identityattributemetadata1.0] (Hardt, D., Identity Attribute Metadata, October2006.). Often format type proposals will accompany an attribute type proposal; in this case it is acceptable to combine the two proposals. The first step in proposing a new attribute format type is to search the list of existing types for similar types. Duplication of format types should be avoided. Post an "intent to define" message to the mailing list at [EMAIL PROTECTED] The email should describe the proposed type in general terms. Posting this to the list will reduce duplicated effort in the case of multiple parties defining similar types. Intent posts will also generate discussion that may be used to determine if it is worthwhile to pursue the proposal. The format type should be completely described both in regular prose and in the meta-data format defined in [identityattributemetadata1.0] (Hardt, D., Identity Attribute Metadata, October2006.). Post a "proposed format type" message to the mailing list at [EMAIL PROTECTED], including the motivation, description and meta-data. An administrator will post the attribute type meta-data to the experimental http://openid.net/type/x/ area. Discussions on the list will dictate whether or not the proposal passes. If the consensus is that the proposed format type is worth pursuing, the type will be moved into the non-experimental name space and the [EMAIL PROTECTED] list notified. TOC 4.3. Attribute Type Identifiers Attribute type identifiers should be created with the following considerations: Attribute type identifiers MUST conform to the generic URI syntax described in [RFC2396] (Berners-Lee, T., Fielding, R., and L. Masinter, Uniform Resource Identifiers (URI): Generic Syntax, August1998.). The OpenID authority portion of the URI is schema.openid.net. Each URI resolves to an RDF representation of the type's meta-data as defined in [identityattributemetadata1.0] (Hardt, D., Identity Attribute Metadata, October2006.). URIs should, where possible, re-use existing paths in the schema.openid.net namespace. The URI path should be kept as short as possible. URI fragment specifiers should not be used. TOC 5. References TOC 5.1.Normative References [OpenID.attribute-exchange-1.0] Hardt, D., OpenID Attribute Exchange, August2006 (TXT, HTML). [OpenID.authentication-2.0] Recordon, D., Hoyt, J., and B. Fitzpatrick, OpenID Authentication 2.0 - Draft 08, August2006 (TXT, HTML). [W3C.REC-xmlschema-2-20041028] Biron, P. and A. Malhotra, XML Schema Part 2: Datatypes Second Edition, World Wide Web Consortium RecommendationREC-xmlschema-2-20041028, October2004 (HTML). [identity-attribute-metadata-1.0] Hardt, D., Identity Attribute Metadata, October2006 (TXT, HTML). TOC 5.2.Non-normative References [RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, Uniform Resource Identifiers (URI): Generic Syntax, RFC2396, August1998 (TXT, HTML, XML). TOC Author's Address Dick Hardt Sxip Identity 798 Beatty Street Vancouver, BC V6B 2M1 CA Email: [EMAIL PROTECTED] URI: http://sxip.com/ ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Identity Attribute Metadata Draft 1
directive pointing to an XSL template that translates the metadata into a human readable format. TOC 3.2.1. Standard Predicates The standard predicates that MUST be in all metadata records are: http://www.w3.org/1999/02/22-rdf-syntax-ns#type The rdf:type predicate has as its object the XML Schema data type or a type defined as per Section3.1 (Data Format Types). http://www.w3.org/2000/01/rdf-schema#label The label is a short description of the attribute type. XML provides an xml:lang attribute that can be used on this element to provide a way to describe the language as per [RFC4646] (Phillips, A. and M. Davis, Tags for Identifying Languages, September2006.) used for the content of the element. Using language tagging in this way, multiple labels can be provided for localization purposes. http://www.w3.org/2000/01/rdf-schema#comment The rdfs:comment element is used to provide a long textual description of the attribute type. As for the rdf:label element, multilingual documentation is supported by the language tagging feature of RDF literals. TOC 3.2.2. Supplemental Predicates These predicates are optional and MAY be included in metadata records: http://schema.openid.net/metadata#example Example value data for the attribute type. http://www.w3.org/2000/01/rdf-schema#seeAlso Indicates a resource that might provide additional information about the subject attribute type. http://schema.openid.net/metadata#acquisition The object of this predicate is a URL from which the IdO may be acquired. Multiple URLs may be specified. The acquisition mechanism is not specified, but would be retrieved using a discovery mechanism specific to the protocol being used. http://schema.openid.net/metadata#authority Except in the case of a self-asserted IdO, a list of authority URIs for asserted claims is necessary. Each URI is that of an assertion authority that is allowed to make the IdO claim. TOC 3.2.3. Example A brief example of the standard predicates and the openid:example element as applied to the http://schema.openid.net/namePerson/first attribute type. ?xml version="1.0"? ?xml-stylesheet type="text/xsl" href=""? rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#" xmlns:openid="http://schema.openid.net/metadata#" rdf:Description rdf:about="http://schema.openid.net/namePerson/first" rdfs:label First name /rdfs:label rdfs:comment First or given name of subject /rdfs:comment openid:example John /openid:example rdf:type rdf:resource="http://www.w3.org/2001/XMLSchema#normalizedString"/ openid:acquisition rdf:resource="http://example.gov/id"/ /rdf:Description /rdf:RDF TOC 4. Future Directions Additional metadata information may be added as more complex attribute types are constructed. The following sections outline possible extensions to the existing simple type definitions. TOC 4.1. Compound Properties The IdO may also be composed of an aggregate of other IdO types, in which case the aggregate IdO URIs will be referenced. TOC 4.2. Equivalents An IdO may make a claim that is equivalent to the claim of an IdO of a different type. The equivalent IdO types are listed in this section. An IdO may be transformed to one of a different type if it is listed as an equivalent. This property is not commutative. This information may be extended to include translation mechanisms between format types. A richer transform specification would allow claims to be made based on a broader equivalence domain. TOC 4.3. Higgins Ontology Predicates The Higgins project has created a base ontological vocabulary at [HigginsOntology] (Trevithick, P., Higgins Ontology v1.10, October2006.). Use of this vocabulary allows for the integration of the attribute types into a broader catalog. TOC 5. References TOC 5.1.Normative References [OpenID.attribute-exchange-1.0] Hardt, D., OpenID Attribute Exchange, August2006 (TXT, HTML). [RFC2119] Bradner, S., Key words for use in RFCs to Indicate Requirement Levels, BCP14, RFC2119, March1997 (TXT, HTML, XML). [RFC4646] Phillips, A. and M. Davis, Tags for Identifying Languages, BCP47, RFC4646, September2006. [W3C.REC-xmlschema-2-20041028] Biron, P. and A. Malhotra, XML Schema Part 2: Datatypes Second Edition, World Wide Web Consortium RecommendationREC-xmlschema-2-20041028, October2004 (HTML). TOC 5.2.Informative References [Higgins-Ontology] Trevithick, P., Higgins Ontology v1.10, October2006. TOC Author's Address Dick Hardt Sxip Identity 798 Beatty Street Vancouver, BC V6B 2M1 CA Email: [EMAIL PROTECTED] URI: http://sxip.com/ ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Identity Attribute Metadata Draft 1
for Identifying Languages,” September 2006.) used for the content of the element. Using language tagging in this way, multiple labels can be provided for localization purposes. http://www.w3.org/2000/01/rdf-schema#comment The rdfs:comment element is used to provide a long textual description of the attribute type. As for the rdf:label element, multilingual documentation is supported by the language tagging feature of RDF literals. TOC 3.2.2. Supplemental Predicates These predicates are optional and MAY be included in metadata records: http://schema.openid.net/metadata#example Example value data for the attribute type. http://www.w3.org/2000/01/rdf-schema#seeAlso Indicates a resource that might provide additional information about the subject attribute type. http://schema.openid.net/metadata#acquisition The object of this predicate is a URL from which the IdO may be acquired. Multiple URLs may be specified. The acquisition mechanism is not specified, but would be retrieved using a discovery mechanism specific to the protocol being used. http://schema.openid.net/metadata#authority Except in the case of a self-asserted IdO, a list of authority URIs for asserted claims is necessary. Each URI is that of an assertion authority that is allowed to make the IdO claim. TOC 3.2.3. Example A brief example of the standard predicates and the openid:example element as applied to the http://schema.openid.net/namePerson/first attribute type. ?xml version=1.0? ?xml-stylesheet type=text/xsl href=schema.xslt? rdf:RDF xmlns:rdf=http://www.w3.org/1999/02/22-rdf-syntax-ns#; xmlns:rdfs=http://www.w3.org/2000/01/rdf-schema#; xmlns:openid=http://schema.openid.net/metadata#; rdf:Description rdf:about=http://schema.openid.net/namePerson/first; rdfs:label First name /rdfs:label rdfs:comment First or given name of subject /rdfs:comment openid:example John /openid:example rdf:type rdf:resource=http://www.w3.org/2001/XMLSchema#normalizedString/ openid:acquisition rdf:resource=http://example.gov/id/ /rdf:Description /rdf:RDF TOC 4. Future Directions Additional metadata information may be added as more complex attribute types are constructed. The following sections outline possible extensions to the existing simple type definitions. TOC 4.1. Compound Properties The IdO may also be composed of an aggregate of other IdO types, in which case the aggregate IdO URIs will be referenced. TOC 4.2. Equivalents An IdO may make a claim that is equivalent to the claim of an IdO of a different type. The equivalent IdO types are listed in this section. An IdO may be transformed to one of a different type if it is listed as an equivalent. This property is not commutative. This information may be extended to include translation mechanisms between format types. A richer transform specification would allow claims to be made based on a broader equivalence domain. TOC 4.3. Higgins Ontology Predicates The Higgins project has created a base ontological vocabulary at [Higgins‑Ontology] (Trevithick, P., “Higgins Ontology v1.10,” October 2006.). Use of this vocabulary allows for the integration of the attribute types into a broader catalog. TOC 5. References TOC 5.1. Normative References [OpenID.attribute-exchange-1.0] Hardt, D., “OpenID Attribute Exchange,” August 2006 (TXT, HTML). [RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML). [RFC4646] Phillips, A. and M. Davis, “Tags for Identifying Languages,” BCP 47, RFC 4646, September 2006. [W3C.REC-xmlschema-2-20041028] Biron, P. and A. Malhotra, “XML Schema Part 2: Datatypes Second Edition,” World Wide Web Consortium Recommendation REC-xmlschema-2-20041028, October 2004 (HTML). TOC 5.2. Informative References [Higgins-Ontology] Trevithick, P., “Higgins Ontology v1.10,” October 2006. TOC Author's Address Dick Hardt Sxip Identity 798 Beatty Street Vancouver, BC V6B 2M1 CA Email: [EMAIL PROTECTED] URI:http://sxip.com/ ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OpenID Auth 2.0 and user-agent neutrality (or, OpenID with REST/SOAP)
On 19-Nov-06, at 3:08 PM, Adam Nelson wrote: Great start on the Wiki. Note that there are some efforts in IETF for enhancing what can be done at the TLS layer for authentication which would enable the same mechanism to be used not only for HTTP, but for SMTP, POP3, IMAP ... Hmm, that's intriguing; I wasn't aware of that. Do you have a pointer to some work product? It was the direction a number of people in the HTTP-AUTH and DIX list were looking at going. Have not heard of an updated status since the last IETF, sorry. Also, most REST implementations have a process for acquiring a token, and then including that token in the XML message. What do you think of tweaking the existing OpenID Authentication response so that the RP returns a token for use in later calls? Interesting. So, you're suggesting the owner of an identity provision an API key interactively using the existing authentication mechanism, and subsequent non-interactive REST API calls would use this API key to authenticate? Or am I misunderstanding? You are understanding. I had considered that, and it would certainly work, but what I found unfortunate about that arrangement is that the authentication of the identity is decoupled from the API calls themselves, so the user couldn't, for example, revoke permission to use her identity with that API, since an API key would already be provisioned. Of course, the API keys could have expiration dates, but that opens up its own usability problems. Note that revocations are challenging to implement. :-) I guess another way to look at it is that the API key is conceptually equivalent to a cookie used by an RP to preserve authentication state with the user agent. The difference to my mind is that, when the cookie expires, the user can reauthenticate, so an expiration of 30 or 60 minutes is probably reasonable, but when an API key expires, the user agent has no way to re-authenticate without parsing some HTML and composing a POST to the IdP, which is the arrangement I'm hoping to avoid. Unless I am missing something, the user needs to be part of the process of generating a token regardless. Will you be at IIW? This would be a great session there. -- Dick ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: IdP's Advertising Both http and https
On 9-Nov-06, at 7:45 AM, Rowan Kerr wrote: On Wed, 2006-11-08 at 00:42 -0800, Dick Hardt wrote: -Original Message- From: Recordon, David But the security warnings will still exist: - RP redirects me to http on IdP - IdP redirects me to https on IdP for login page (warning) no warning on GET redirects If GET is going to be an acceptable method for responses, the spec should be updated. Section 5.2.1. HTTP Redirect states: This method is deprecated as of OpenID Authentication version 2.0 though is still required for implementation to aide in backwards compatibility. To clarify, the GET redirect that I am referring to is one to is to the same host. We moved to a POST between RP and OP so that we could move more data. -- Dick ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OpenID Auth 2.0 and user-agent neutrality (or, OpenID with REST/SOAP)
Hi Adam The switch from GET to POST was made so that we were not constrained by the URL parameter payload limit. As you point out, HTTP headers can be used for moving messages as well, but there was no clear mechanism to do that without modifying all the widely available browsers. I think REST support is a really useful feature, and have described how that might happen in the past, but right now we are pretty focussed on getting browser based auth finalized, and I think the mechanisms for rich clients will be related, but slightly different. -- Dick On 12-Nov-06, at 5:24 PM, Adam Nelson wrote: I've been tracking OpenID auth from 1.0 with great interest. Last summer Johannes Ernst explained to me how it was that one might use openid to authenticate a non-interactive user agent such as a REST API consumer by intercepting the RP's redirect and providing the info from the IdP itself. Given OpenID's design goals (decentralized, lightweight, flexible identity management), and its seemingly inevitable adoption into the mashup-minded web 2.0 ecosystem (God help me I'm buzzwording!), it seems to me that OpenID's value is significantly enhanced if the identities it enables can be used to authenticate to SOAP and REST APIs as well as interactive web sites. Having said that, I was surprised to note in draft 10 of OpenID Auth 2.0 that the HTTP redirect method of communication between the RP and the IdP is deprecated in favor of an HTML forms-based approach. This suggests to me that OpenID Auth 2.0 is not compatible with REST or SOAP or any other binding that doesn't involve the exchange, parsing, and submission of HTML forms. I'm curious why this decision was made, and if its implications have been fully considered. Has there been any thought given to an alternative means of authentication, perhaps via custom HTTP headers or some other non-HTML means? If not, does this mean OpenID is not intended to support authentication to programmatic APIs? Thanks, Adam ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Map/Normalize Email Address to IdP/OP URL (Was [PROPOSAL] Handlehttp://[EMAIL PROTECTED] Style Identifiers)
On 10-Nov-06, at 7:20 AM, David Fuelling wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jonathan Daugherty # I think that all this discussion about email userid is moving us off # track. My original proposal was that the email maps/normalizes to a # URL of an IdP (the userid is ignored/not used). # # So, '[EMAIL PROTECTED]' would be treated as if the User had entered # 'http://any.edu' (the URL of their IdP/OP) into the OpenId login # form. Then why not just enter 'http://any.edu' or 'any.edu' instead? -- Jonathan Daugherty JanRain, Inc. True, there's almost no difference on the OpenId side. On the human side, email is more familiar to a typical user (e.g., my Dad) who may not know to try and strip off the dad@ part of his email to use with OpenId. Plus, why do we **not** want OpenId to work with email addresses (assuming we maintain the principals of User Centric Identity if we use them?) I strongly have the view that [EMAIL PROTECTED] is a really bad idea. Your dad is not providing his password to the RP, and should not be prompted for his username there. He should be prompted for the site he wants to get sent to where he can then enter his credentials. This model is something your dad is likely even more familiar with, typing in hostname into the address bar. Typing in the site where he logs in is what he does at the OpenID prompt. btw: why is this thread cross posted? -- Dick ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: XRDS vs. DNS level identity (was RE: [PROPOSAL] Handle http://[EMAIL PROTECTED] Style Identifiers)
I agree with Johannes here. DNS is not user accessible (for good reason) Documents on a web server are relatively more accessible. wrt. DNS, I think DNSSEC could have a significant role in providing server to server discovery, specifically of key key material. -- Dick On 8-Nov-06, at 8:00 PM, Johannes Ernst wrote: Just commenting on the XRDS discovery from HTTP URLs bit. Using DNS as a mechanism, given a URL, to discover the location of, or obtain the content or equivalent of, the XRDS file, was proposed back then in Yadis 0.x days, and rejected. The reason being that any such mechanism would require the system administrator in charge of the DNS system to configure XRDS for any and all users in that domain. It would give that system administrator an effective veto (exercised by being lazy, for example) over whether or not users could use OpenID on that domain, and in particular which services to reference from that file (e.g. competitive services). There was general consensus that for a user-centric identity system, that was not desirable, and that's why we decided in favor of the HTTP header extension, its HTML equivalent, and the shortcut via the MIME type. We felt on safe ground with respect to naming design, because it's very much the same approach as, say, the reference of embedded GIFs or CSS in HTML, or the use of URLs to identify DTDs in XML. On Nov 8, 2006, at 17:19, Hallam-Baker, Phillip wrote: Quite a few years went into the design of DNS. The concern I have here is that to influence the wider network is a very serious challenge. Innovation in naming is the single hardest thing to do in a network protocol. I have seen UDDI, Realnames, X.500, so many proposals. When someone tells me a simple thing is too complex and then proposes to do the single hardest, most complex thing in computer networking I have concerns. -Original Message- From: Drummond Reed [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 08, 2006 7:42 PM To: Hallam-Baker, Phillip; Recordon, David; 'David Fuelling' Cc: specs@openid.net; [EMAIL PROTECTED] Subject: XRDS vs. DNS level identity (was RE: [PROPOSAL] Handle http://[EMAIL PROTECTED] Style Identifiers) Phillip, Please don't shoot me -- I am just the messenger -- but a year-long effort (Yadis) went into the design and deployment of XRDS documents as the discovery infrastructure for OpenID. There are numerous reasons for this, but they boil down to this: the XRDS layer of identity is rooted at a higher layer than that of DNS. Users don't just have DNS names in OpenID; they have URLs or XRIs. Those URLs or XRIs resolve to XRDS documents, which perform mapping of URLs/XRIs to URI-identified service endpoints. These service endpoint URIs in turn map down to services resolvable at the DNS layer (which then of course map down to machine addresses at the IP layer). I fully understand that you have seen so many attempts to reinvent it (the DNS). OpenID and URL/XRI-based identity is not an attempt to reinvent it. It is the emergence of identity infrastructure at a higher layer designed to take advantage of the abstractions available at that layer, including: * URI and XRI syntax (much richer than DNS) * HTTP and HTTPS protocols for discovery * Extensible, XML-encoded resource description metadata * Mapping of reassignable and persistent identifiers for persistent identity * Discovery of typed service endpoints I know you know my personal bias (anyone who would push the XRI boulder this long uphill has got to have a few screws loose), but at this point it seems like trying to push the XRDS layer back down into DNS would be like trying to put the genie back in the bottle. =Drummond -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hallam-Baker, Phillip Sent: Wednesday, November 08, 2006 3:01 PM To: Recordon, David; David Fuelling Cc: specs@openid.net; [EMAIL PROTECTED] Subject: RE: [PROPOSAL] Handle http://[EMAIL PROTECTED] Style Identifiers You can make things complex in two ways, one is by adding too many curlicues to a design, another is by refusing to use the deployed infrastructure for its intended purpose. The signaling and discovery infrastructure of the Internet is the DNS. I have seen so many attempts to reinvent it. -Original Message- From: Recordon, David Sent: Wednesday, November 08, 2006 4:50 PM To: Hallam-Baker, Phillip; David Fuelling Cc: specs@openid.net; [EMAIL PROTECTED] Subject: RE: [PROPOSAL] Handle http://[EMAIL PROTECTED] Style Identifiers Involving DNS seems to make this too complex. If we're going to involve DNS, we might as well re-architect Yadis to use it as yet another discovery option. --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hallam-Baker, Phillip Sent: Wednesday, November 08, 2006 1:37 PM To: David Fuelling Cc:
Re: IdP vs OP (WAS: RE: Editors Conference Call)
On 6-Nov-06, at 11:46 AM, Recordon, David wrote: I see both sides of this discussion. I think John is correct that the role of an OP really is not that different than that of SAML's IdP. The difference comes down to the trust model. I certainly think reputation networks will exist which rate OPs, RPs, users, etc and will ultimately be needed for a technologies with promiscuous trust models to thrive in a large scale. I guess reading more of this is making me question if renaming IdP really is the best thing to do in OpenID. I think if anything we all, as a larger community, should be working to bring OpenID and SAML closer together versus driving them further apart. I don't see this as driving SAML apart from OpenID. I see it as differentiating OpenID as being user-centric vs federated. The IdP has specific meaning in the federated world. A key differentiator with OpenID is that trust is not needed between the OP and the RP. It is implied and perhaps needed in the IdP / RP relationship. -- Dick ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
