Re: [OpenID board] OAuth Hybrid and UI ML?
This is where our process I think is broken. Without a service like agree2.com to make collecting the agreements, I don't see how this can be done in a transparent, transferrable way. How have other groups managed this? Is this why our WG process is so encumbered and broken? On Mon, Jun 15, 2009 at 12:41 PM, Allen Tom a...@yahoo-inc.com wrote: Hi David, I can take care of moderating the UI mailing list. Am I responsible for collecting the contribution agreements myself? Allen David Recordon wrote: Once the working groups are approved and someone is willing to moderate new members on the list to make sure they've signed contribution agreements before posting, I can make the list itself. --David On Jun 11, 2009, at 6:21 PM, Allen Tom wrote: Hi Nat, How does one create a mailing list? At least with regards to the OpenID UI WG, we're just mailing each other directly. Allen Nat Sakimura wrote: Hi. I just found out that the Mailing list for OAuth Hybrid WG and UI WG are not listed on http://openid.net/mailman/listinfo/ . http://openid.net/mailman/listinfo/ To make sure equal participation, we should make it possible for people to find out about them. Are they established at all? Where is the discussion being conducted right now? -- Nat Sakimura (=nat) http://www.sakimura.org/en/ -- ___ specs mailing listsp...@openid.nethttp://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ board mailing list bo...@openid.net http://openid.net/mailman/listinfo/board -- Chris Messina Open Web Advocate Personal site: http://factoryjoe.com Twitter: http://twitter.com/chrismessina Diso Project: http://diso-project.org OpenID Foundation: http://openid.net This email is: [ ] bloggable[X] ask first [ ] private ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: SREG's Privacy Policy URL
I worry a little about dumping this into the UX extension, because it's not the logical place to look for it. Instead (and our WG process is really effed here), perhaps we should have a Policy Expression Extension (acronym pending) so that we could express things like this: xrds:XRDS XRD Typexri://$xrds*simple/Type !-- Privacy Policy -- Service Typehttp://schemas.openid.net/policies/privacy/Type URIhttp://example.com/privacy.php/URI /Service !-- Terms Conditions -- Service Typehttp://schemas.openid.net/policies/terms/Type URIhttp://example.com/terms_and_conditions.php/URI /Service /XRD /xrds:XRDS I also think that RP discovery makes a lot of sense, and that really this stuff should all live in /host-meta. Chris On Tue, Jun 2, 2009 at 11:14 AM, Allen Tom a...@yahoo-inc.com wrote: OK, how about if we define a new Privacy Policy Service for RPs to include in their XRDS, with a link to their privacy policy? So the RP would just include the following snippet in its discovery document, discoverable under its realm: Service Typehttp://specs.openid.net/path/to/privacy/policy/type URIhttp://www.relyingparty.com/path/to/privacy/policy.html /Service I'm not sure where we can formally document this. I guess we can put it in the UI spec? Allen George Fletcher wrote: I think for a short-term solution we'd need to define service types for the privacy policy and TOS for XRDS. For the long-term, the same could potentially be used as rel values in the XRD markup. The XRD spec is solidifying but is not 100% stable. I think we should have a discovery option regardless of whether we update UX or AX. So I'd like to see a proposal for XRDS and then when XRD is available, supporting that. Thanks, George Allen Tom wrote: Hi Luke, Yes, this is what we're looking for. Currently, in OpenID, the only way for the RP to link to its privacy policy (which is sort of like linking to its ToS) is by passing it in the openid.sreg.policy_url parameter using SREG. Since we're trying to deprecate SREG, we can try to move this parameter to either the UI or AX Extension, or move it into Discovery. Is there an actual Discovery spec? Allen Luke Shepard wrote: FWIW, Facebook Connect allows relying parties to define a “terms of service” url. We then show that link to users when they click on it. With OpenID, the equivalent URL would be set using relying party discovery. Is this more or less what you’re looking for? Screenshot: On 6/2/09 10:21 AM, Allen Tom a...@yahoo-inc.com wrote: Alternatively, the RP could publish its privacy policy in its discovery document, which does make a lot of sense, but I understand that there's a lot of work going on to define the next generation of discovery, and I'm not quite sure what the timeframe is for that. ___ 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 Open Web Advocate Website: http://factoryjoe.com Blog: http://factoryjoe.com/blog Twitter: http://twitter.com/chrismessina Diso Project: http://diso-project.org OpenID Foundation: http://openid.net This email is: [ ] bloggable[X] ask first [ ] private ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Request to consider creation of the User Interface Work Group
+1! I think this is very good progress, with a well-defined scope and plenty of interest so far. Let's make this happen! Chris On Fri, Feb 20, 2009 at 4:06 PM, Allen Tom a...@yahoo-inc.com wrote: +1! Improving OpenID UX and adding support for internationalization should definitely be done ASAP. The scope is focused and well defined, and I'm confident that we will be able to quickly write a very short spec that will greatly improve OpenID's usability and demonstrate our commitment to deploy OpenID worldwide. (I might be a bit biased) Allen 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 ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs -- Chris Messina Citizen-Participant Open Web 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
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: Joining OpenID Spec List
Welcome! Not to be curt, but has Facebook signed a non-assert on OpenID IPR? If you plan to contribute (I hope so!!), would you be able to? Chris On Tue, Oct 28, 2008 at 7:42 AM, Dave Morin [EMAIL PROTECTED] wrote: Hey everyone, Just finished talking with David Recordon for a bit and have decided to join the OpenID Spec list. Happy to be here and contribute. It was great seeing many of you at the OpenID UEX Summit last week. Dave ___ 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: Email Address to URL Transformation
You can find out more information about EAUT and Emailtoid here: http://eaut.org/ http://emailtoid.net The specification is available here: http://eaut.org/specs/1.0/ We do hope to turn this into an extension to OpenID as it attempts to directly address the criticism about OpenID that people don't tend to think of themselves as URLs but instead identify themselves by email addresses. I wrote more about this here (for context): http://factoryjoe.com/blog/2008/06/22/announcing-emailtoid-mapping-email-addresses-to-openids/ Chris On Tue, Aug 12, 2008 at 9:19 PM, [EMAIL PROTECTED] wrote: Formal answer is no. I think Vidoop will eventually propose to form a working group on this eventually, but that is only my guess. =nat On 8/13/08, Arshad Khan [EMAIL PROTECTED] wrote: Does OpenID 2.0 support 'Email Address to URL Transformation (EAUT)? There is some info on this page of what EAUT is: http://blog.vidoop.com/archives/139 Has Vidoop developed this outside OpenID 2.0 framework? Thanks. Arshad -- Nat Sakimura (=nat) http://www.sakimura.org/en/ ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs -- Chris Messina Citizen-Participant Open Source 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: OpenID Inline Authentication Extension 1.0 Draft 1
Has anyone done a comparison between this spec and OAuth? It really seems like an unnecessary duplication of work given the 8 months we've put into it so far... Chris Sent from my iPhone On Sep 3, 2007, at 2:22 PM, Martin Atkins [EMAIL PROTECTED] wrote: John Ehn wrote: Martin, Thanks for the response! I'm looking at those specs now, and I really like the flow of the HTTP Authentication spec, because it looks like it's solving the problem of passing the OpenID Identifier to the RP in an automated way, which is really cool. Looks like it needs to be fleshed out in some parts, though. Both of these specs need work. What you see up there on the wiki is really just a brain dump wanting to be turned into a spec. I've not really had much time to work on them, though. As for the Signature Request protocol, I'm not quite sure what it does yet, but I'll let you know my opinion once I've digested it. The HTTP Authentication spec has a part in it where it says the client must get a signature from somewhere. When I originally specced it my only answer here was that non-human agents can act as their own OP and therefore they could just compute the signature themselves, but realising that this protocol had applications for humans authenticating to services inside specialised rich clients (Last.fm's Audioscrobbler API, for example, or JOSM for OpenStreetMap) I added Signature Request Protocol as a standard mechanism for rich client RPs to obtain a signature from the user's OP. As I think it notes somewhere in the copy, I'm imagining in the ideal case a desktop service or at least a shared library that does the SRP bit on behalf of all of the user's applications, so that each application does not need to be given the user's OP credentials. It was my hope that it could theoretically be integrated with systems like Apple's Keychain. However, SRP is still very rough-and-ready and still has lots of outstanding issues. I think Inline Authentication might have the answer to some of these issues. Cheers, Martin ___ 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 Trusted Authentication Extension
Hi John, Looks like there's some consensus around OAuth... ;) I helped to get OAuth off the ground to solve the very problem that you're looking to solve -- in our case, enabling Ma.gnolia OpenID users to use Dashboard Widgets and Twitter API users to authenticate their apps, eventually using OpenID. While I appreciate your work on an OpenID-specific extension, I think there's some legitimacy in looking at a solution that works generally regardless of the authentication mechanism. By decoupling OpenID and OAuth, the goal was to make it easier to adopt OAuth first and then lead into adopting OpenID. In the case of your spec, which seems like a good piece of work, there'd be no sense in supporting the extension without supporting OpenID and as such, has limited benefit in the wild for implementors. With OAuth, if we're able to get folks like AOL, Google, Yahoo and others to support it, the amount of effort necessary to support all of them becomes the same amount of work to support one. Anyway, I'm glad to see you on the OAuth list. Feel free to poke around; we're looking to put out a 0.9 Draft and have it implemented over the course of September in libraries and then release finally a 1.0 Oct 1. Cheers, Chris On 8/27/07, David Fuelling [EMAIL PROTECTED] wrote: John, Have a look at OAuth (http://groups.google.com/group/oauth). I think it's currently a private google group, but it seems like you've given a lot of thought to this type of thing, so I'm sure the group owners would welcome your input. There's a lot of activity going on over there. David On 8/26/07, John Ehn [EMAIL PROTECTED] wrote: I have created a draft of a new specification that I think will help to fill a gap in OpenID functionality. What appears to be a newer productivity feature of many websites is the ability to import and utilize information from other sites. For instance, Basecamp provides an API that allows other systems to access user data. This is a great feature, but it currently cannot be done with OpenID, due to the dependence on end-user interaction during the authentication process. The Trusted Authentication Extension provides for the ability for an OpenID Consumer to log in to another OpenID Consumer without user interaction. The end user will be able to create a trusted connection between two OpenID enabled sites, which will allow a client site to access a destination site using the end user's Identity. Please provide your comments and feedback, as they are most appreciated. http://extremeswank.com/openid_trusted_auth.html Thank you, John Ehn [EMAIL PROTECTED] ___ 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 Provocateur Open Source Advocate-at-Large Work: http://citizenagency.com Blog: http://factoryjoe.com/blog Cell: 412 225-1051 Skype: factoryjoe This email is: [ ] bloggable[X] ask first [ ] private ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Promoting OpenID
I thought it was interesting to discover this: http://www.atlassian.com/software/crowd/ On the one hand, this is interesting from a marketing perspective, and I think we need more education materials and demonstrations of how this technology can be used. On the other, I personally think selling to the enterprise is nearly impossible without tons of grassroots adoption (think: Firefox) who will their feet to the fire, at which point, we can tell them that we have a bucket of water called OpenID that they can implement to alleviate the burn. But that's just how I roll. :) Chris On 4/4/07, Wes Kussmaul [EMAIL PROTECTED] wrote: As long as we're being ecumenical about platforms can we include Shibboleth, i-name etc. along with OpenID in user-centric identity? If so I am interested. Wes Kussmaul McGovern, James F (HTSC, IT) wrote: Great to hear that you are working with salesforce.com. Would someone else on this list volunteer to work with Siebel, Peoplesoft, SAP, Intalio and Alfresco? -Original Message- From: Dick Hardt [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 04, 2007 2:57 AM To: McGovern, James F (HTSC, IT) Cc: specs@openid.net Subject: 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 ... * 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 -- Chris Messina Citizen Provocateur Open Source Ambassador-at-Large Work: http://citizenagency.com Blog: http://factoryjoe.com/blog Cell: 412 225-1051 Skype: factoryjoe This email is: [ ] bloggable[X] ask first [ ] private ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
