Re: OPs to advertise support for OpenID extensions via the extension's type URI
Sounds good to me! On Jul 22, 2009, at 5:23 PM, John Bradley wrote: +1 I think that advertising the extension itself is a good practice. A RP may prefer OPs that support the extension over ones that don't. That is the case for PAPE now as an example. With XRD most of that will be described in the OPs XRD rather than the users, but the same principal should apply. John B. On 22-Jul-09, at 12:00 PM, specs-requ...@openid.net wrote: From: Breno de Medeiros br...@google.com Subject: Re: OPs to advertise support for OpenID extensions via the extension's type URI To: Andrew Arnott andrewarn...@gmail.com Cc: specs@openid.net Message-ID: 29fb00360907221019t10a0393aydbae458ba8c66...@mail.gmail.com Content-Type: multipart/alternative; boundary=00151750e13a821afc046f4e91df --00151750e13a821afc046f4e91df Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I agree with Andrew on this suggestion. I don't think the UI WG proceeded differently for any particular reason, except that no such convention existed and we were not aware of side-effects previously. Regardless of interoperability issues with existing libraries, I thinking having a type URI for the extension is desirable from purely semantic standpoint (if a human were to read such document, it would be more logically organized with 'umbrella' type URIs for the extension). ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: experimental namespace for openid.net
Should this experimental namespace only apply to work being done by
OpenID working groups? I'm very supportive of pushing the standards
forward via prototypes, but that should be done as part of the OpenID
community instead of by a single company.
I'd be very happy to help get a discovery working group spun up and
charter them to modernize OpenID 2.0's discovery process.
--David
On Jul 10, 2009, at 11:58 AM, George Fletcher wrote:
+1 to http://experimental.openid.net
It would be good to add this to the repository work Breno and John
are doing as having a registry for experimental URIs would be good
as well.
Thanks,
George
Dirk Balfanz wrote:
[+gene...@openid.net mailto:gene...@openid.net for a broader
audience]
On Thu, Jul 9, 2009 at 4:45 PM, Dirk Balfanz balf...@google.com mailto:balf...@google.com
wrote:
Hi guys,
Google would like to launch a feature in which we're allowing our
Google Apps hosted domains to become OpenID providers. The
authentication part of it is pretty simple - Google is already
logging in users to their apps, so we can also host an OP endpoint
for those domains and send assertions back to Relying Parties.
What is more difficult is the discovery part. We have been working
with the XRI TC to define a XRD-based discovery protocol that
would allow this kind of hosting of discovery documents on behalf
of our customers.
We believe that providing proof-of-concept implementations drives
standardization processes forward, so in this spirit we want to
launch this feature in the near future, using a discovery protocol
that as far as we can tell meets all the requirements of what the
XRI TC is currently converging on, but which has not been vetted
as an official standard (it's a chicken and egg thing - without
PoC no standards, without standards by definition no
standards-compliant implementations).
While we were tossing around ideas http://markmail.org/message/ixc5led2lobdwij2
in the
standardization committees we just used random identifiers for new
XML namespaces, etc. that we would need for this discovery
protocol. Now that we're about to launch we need to decide what to
call these things. We would like to use a namespace
in http://specs.openid.net/... because we want this kind of
discovery protocol to be part of OpenID, but we can't really use
them because we don't have a next-generation discovery protocol
yet.
So what should we use? How
about http://experimental.openid.net/... ? That way, Relying
Parties know that what we're trying to do is be a part of the
OpenID community and bring the protocol forward. On the other
hand, this would also be a signal to the RP that they're using a
feature that has not been vetted as a standard yet.
For example, a discovery document for a domain balfanz.net
http://balfanz.net at Google might look like this (notice the
experimental namespace and the XML elements using it):
?xml version=1.0 encoding=UTF-8?
xrds:XRDS xmlns:xrds=xri://$xrds xmlns=xri://$xrd*($v*2.0)
ds:Signature xmlns:ds=http://www.w3.org/2000/09/xmldsig#;
ds:SignedInfo
ds:CanonicalizationMethod Algorithm=http://docs.oasis-open.org/xri/xrd/2009/01#canonicalize-raw-octets
/
ds:SignatureMethod Algorithm=http://www.w3.org/2000/09/xmldsig#rsa-sha1
/
/ds:SignedInfo
ds:KeyInfo
ds:X509Data
ds:X509Certificate
MIICgjCCA...
/ds:X509Certificate
ds:X509Certificate
MIICsDCCAhmgAwIB...
/ds:X509Certificate
/ds:X509Data
/ds:KeyInfo
/ds:Signature
XRD
CanonicalIDbalfanz.net http://balfanz.net/CanonicalID
Service priority=0
Typehttp://specs.openid.net/auth/2.0/server/Type
Typehttp://openid.net/srv/ax/1.0/Type
Typehttp://specs.openid.net/extensions/pape/1.0/Type
URIhttps://www.google.com/a/balfanz.net/o8/ud?be=o8/URI
/Service
Service priority=0 xmlns:experimental=http://experimental.openid.net/google/2009/07/xmlns/
Typehttp://www.iana.org/assignments/relation/describedby/
Type
MediaTypeapplication/xrds+xml/MediaType
experimental:URITemplatehttps://www.google.com/accounts/o8/user-xrds?uri=
{%uri}
https://www.google.com/accounts/o8/user-xrds?uri=%7B%uri%7D/
experimental:URITemplate
experimental:NextAuthorityhosted-id.google.com
http://hosted-id.google.com/experimental:NextAuthority
/Service
/XRD
/xrds:XRDS
What do you guys think?
Dirk.
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs
Re: Clarification needed in PAPE spec
Yeah, it was meant to be included with the value of an empty string. --David On Jun 17, 2009, at 10:56 AM, Andrew Arnott wrote: A space-delimited list of no elements is the empty string. So I'd say (and DNOA is coded such that) it cannot be omitted, but may be empty. -- Andrew Arnott I [may] not agree with what you have to say, but I'll defend to the death your right to say it. - S. G. Tallentyre On Wed, Jun 17, 2009 at 10:07 AM, Allen Tom a...@yahoo-inc.com wrote: Another ambiguous parameter is the openid.pape.preferred_auth_policies request parameter in section 5.1. The first sentence in Section 5.1 says that all the request parameters are mandatory (MUST be included), however the description openid.pape.preferred_auth_policies says that zero policies can be specified. Is there a special value for zero policy? Or should the parameter be omitted if the no policy is requested? http://openid.net/specs/openid-provider-authentication-policy-extension-1_0.html#anchor8 Thanks Allen ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OAuth Hybrid and UI ML?
Hey George, Yes, they're open for reading but require a contribution agreement in order to post. Mailman makes this a bit tricky since it means we need to moderate all new users so that you can receive emails but not post yourself. --David On Jun 16, 2009, at 5:00 AM, George Fletcher wrote: Will these lists be open for reading to the community? I'd like to keep up with what's happening in both these groups. Thanks, George David Recordon wrote: Once the working groups are approved and someone is willing to moderate new members on the list to make sure they've signed contribution agreements before posting, I can make the list itself. --David On Jun 11, 2009, at 6:21 PM, Allen Tom wrote: Hi Nat, How does one create a mailing list? At least with regards to the OpenID UI WG, we're just mailing each other directly. Allen Nat Sakimura wrote: Hi. I just found out that the Mailing list for OAuth Hybrid WG and UI WG are not listed on http://openid.net/mailman/listinfo/ . http://openid.net/mailman/listinfo/ To make sure equal participation, we should make it possible for people to find out about them. Are they established at all? Where is the discussion being conducted right now? -- Nat Sakimura (=nat) http://www.sakimura.org/en/ ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net mailto:specs@openid.net http://openid.net/mailman/listinfo/specs = ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OAuth Hybrid and UI ML?
Once the working groups are approved and someone is willing to moderate new members on the list to make sure they've signed contribution agreements before posting, I can make the list itself. --David On Jun 11, 2009, at 6:21 PM, Allen Tom wrote: Hi Nat, How does one create a mailing list? At least with regards to the OpenID UI WG, we're just mailing each other directly. Allen Nat Sakimura wrote: Hi. I just found out that the Mailing list for OAuth Hybrid WG and UI WG are not listed on http://openid.net/mailman/listinfo/ . To make sure equal participation, we should make it possible for people to find out about them. Are they established at all? Where is the discussion being conducted right now? -- Nat Sakimura (=nat) http://www.sakimura.org/en/ ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Requiring Pseudonymous Identifier
Agreed. RP requests a pseudonymous identifier and it's up to the OP to figure out how to make one and ideally communicate back to the RP that it did so. --David On May 13, 2009, at 9:41 AM, Andrew Arnott wrote: Agreed. There is no reason for OpenID to mandate how pseudononymous identifiers are created. That should be left up to the OP. -- Andrew Arnott I [may] not agree with what you have to say, but I'll defend to the death your right to say it. - Voltaire On Wed, May 13, 2009 at 9:28 AM, George Fletcher gffle...@aol.com wrote: I'm perfectly fine with using RP discovery as a mechanism for the RP to specify what policy it requires. I believe that unsolicited assertions are going to become more common, so we need to support it. What I don't want OpenID to do is specify the actual syntax of the pseudonymous identifier. I agree that the RP has to trust the OP (in some sense) or make it's own determination that the OP is not honoring the RP's wishes and then take some action. For RP's behind firewalls, it would be nice to allow them some mechanism other than RP discovery to assert their requirements, but that should preclude the discover option. Thanks, George Andrew Arnott wrote: leaves out the scenario of unsolicited assertions.A new directed identity value that the RP passes to the OP to indicate it wants a psuedononymous identifier. Consider this: An OP needs to perform RP discovery (already), and probably does so before sending an unsolicited assertion in order to find out what the assertion receiving URI would be for a given realm. DNOA does this already. If that RP's XRDS document included a TypeURI element that had a special psuedononymous-identifier-only-please value the OP could pick up on this, and send the unsolicited assertion using the appropriate type of claimed_id. Likewise, when an RP sends an ordinary directed identity request to an OP, the OP would again notice the RP's XRDS during RP discovery and see what kind of identifier the RP wants and assert accordingly. Yes, some OPs won't honor the RP's wishes, and some OPs don't do RP discovery at all. Perhaps to help the RP detect whether the OP respected its wishes would be to send a PAPE extension or some other openid.* parameter to say yes, this is a pseudo- identifier. RPs have no way to analytically be certain that some identifier is psuedononymous anyway, so ultimately the RP has to trust the OP (whether implicitly or through a white list is up to the RP). -- Andrew Arnott I [may] not agree with what you have to say, but I'll defend to the death your right to say it. - Voltaire On Wed, May 13, 2009 at 8:44 AM, George Fletcher gffle...@aol.com mailto:gffle...@aol.com wrote: I don't think OpenID should specify how pseudonymous identifiers are generated. That should be up to the OP. But I like the idea of using a fixed URI as the claimed_id value to specify the behavior desired by the RP. If, however, we need to grow this to cover anonymous based identifiers (i.e. the claims based models from earlier in this thread) then it might make sense to look at a PAPE extension that covers the type of identifier requested. Thanks, George Nat Sakimura wrote: Sorry for a slow response. This week is especially busy for me... I borrowed the notion from Austrian Citizen ID system. In there, the services are divided into sectors. A sector may span several agencies. They call ID as PIN (Personal Identification Number). There is a secret PIN (sPIN) which is not used anywhere but in their SmartCard. Then, sector sepcific PIN (ssPIN) is calculated in the manner of : SHA1(sPIN + SectorID) (Note, there is a bit more details but...) I have thrown OP secret into it. To avoid the analytic attack, I agree that it is better to use individual secret, as some of you points out. Regards, =nat On Tue, May 12, 2009 at 5:55 PM, Dick Hardt dick.ha...@gmail.com mailto:dick.ha...@gmail.com wrote: On 12-May-09, at 1:36 AM, Nat Sakimura wrote: Reason for using RP's Subject in XRD instead of simply using realm is to allow for something like group identifier. would you elaborate on the group identifier concept? This is just one idea. Downside of this approach is that we need to set up a WG. I am sure there are more ideas. It might be possible to utilize AX so that it will only be a profile that does not require a WG. So shall we start discussing which direction we want to go forward? sure! ___ specs mailing list specs@openid.net mailto:specs@openid.net
Re: Requiring Pseudonymous Identifier
Does it make more sense to use a PAPE policy requesting a pseudonymous identifier or an AX attribute requesting one? Any of these approaches would work, I just don't think we've mapped out the pros/cons of each. --David On May 13, 2009, at 8:44 AM, George Fletcher wrote: I don't think OpenID should specify how pseudonymous identifiers are generated. That should be up to the OP. But I like the idea of using a fixed URI as the claimed_id value to specify the behavior desired by the RP. If, however, we need to grow this to cover anonymous based identifiers (i.e. the claims based models from earlier in this thread) then it might make sense to look at a PAPE extension that covers the type of identifier requested. Thanks, George Nat Sakimura wrote: Sorry for a slow response. This week is especially busy for me... I borrowed the notion from Austrian Citizen ID system. In there, the services are divided into sectors. A sector may span several agencies. They call ID as PIN (Personal Identification Number). There is a secret PIN (sPIN) which is not used anywhere but in their SmartCard. Then, sector sepcific PIN (ssPIN) is calculated in the manner of : SHA1(sPIN + SectorID) (Note, there is a bit more details but...) I have thrown OP secret into it. To avoid the analytic attack, I agree that it is better to use individual secret, as some of you points out. Regards, =nat On Tue, May 12, 2009 at 5:55 PM, Dick Hardt dick.ha...@gmail.com wrote: On 12-May-09, at 1:36 AM, Nat Sakimura wrote: Reason for using RP's Subject in XRD instead of simply using realm is to allow for something like group identifier. would you elaborate on the group identifier concept? This is just one idea. Downside of this approach is that we need to set up a WG. I am sure there are more ideas. It might be possible to utilize AX so that it will only be a profile that does not require a WG. So shall we start discussing which direction we want to go forward? sure! ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: RECOMMENDED: Proposal to create the OpenID and OAuth Hybrid Extension working group
Unless there are any objections, I will change this voting period to match that of the CX working group where the vote will open Saturday February 14th. --David - David Recordon da...@sixapart.com wrote: The Specifications Council recommends that the Foundation members approve the creation of the OpenID and OAuth Hybrid Extension working group ( http://openid.net/pipermail/specs-council/2009-January/99.html) , as proposed below and found at http://wiki.openid.net/OpenID-and-OAuth-Hybrid-Extension. If you are a member of the OpenID Foundation, you'll be able to login and vote on the creation of this new working group after this 14-day notice period. The vote thus will be from Wednesday February 11th through Wednesday February 18th. All votes are held in US Pacific Time. --David Background Information OpenID has always been focused on how to enable user-authentication within the browser. Over the last year, OAuth has been developed to allow authorization either from within a browser, desktop software, or mobile devices. Obviously there has been interest in using OpenID and OAuth together allowing a user to share their identity as well as grant a Relying Party access to an OAuth protected resource in a single step. A small group of people have been working on developing an extension to OpenID which makes this possible in a collaborative fashion within http://code.google.com/p/step2/. This small project includes a draft spec and Open Source implementations which the proposers would like to finalize within the OpenID Foundation. Working Group Name OpenID OAuth Hybrid Working Group Purpose Produce a standard OpenID extension to the OpenID Authentication protocol that provides a mechanism to embed an OAuth approval request into an OpenID authentication request to permit combined user approval. The extension addresses the use case where the OpenID Provider and OAuth Service Provider are the same service. To provide good user experience, it is important to present a combined authentication and authorization screen for the two protocols. Scope The proposed work is as follows: * Extend the OpenID authentication request/response and the assertion verification mechanism, to embed an OAuth approval request into an OpenID authentication request. Assuming the OpenID Provider and OAuth Service Provider are the same service. * Insulation of each protocol from the other, both for backwards compatibility as well as to enable OpenID and OAuth to evolve and incorporate additional features without requiring reviews of the combined usage. Especially, to allow future support for unregistered OAuth consumers. * Security analysis and best practices Out of scope * The OpenID extension does not define an unregistered OAuth consumers mode, but instead ensures that such support would be possible by protocol insulation. The unregistered consumers mode should be defined separately in the OAuth specifications. Anticipated Contributions Finalize the OpenID OAuth Extension spec (http://step2.googlecode.com/svn/spec/openid_oauth_extension/drafts/0/openid_oauth_extension.html) as an official OpenID Extension. Proposed List of Specifications OpenID OAuth Extension 1.0. Specification completion by Q1 2009. Anticipated audience or users of the work * OpenID Providers and Relying Parties * OAuth Consumers and Service Providers * Implementers of OpenID Providers and Relying Parties Language in which the WG will conduct business English. Method of work E-mail discussions on the working group mailing list and working group conference calls. Basis for determining when the work of the WG is completed The work will be completed once it is apparent that maximal consensus on the protocol proposal has been achieved within the working group, consistent with the purpose and scope. Proposers * Ben Laurie, b...@google.com, Google * Breno de Medeiros, br...@google.com, Google * David Recordon, drecor...@sixapart.com, Six Apart * Dirk Balfanz, balf...@google.com, Google * Joseph Smarr, jsm...@plaxo.com, Plaxo * Yariv Adan, ya...@google.com, Google * Allen Tom, a...@yahoo-inc.com , Yahoo * Josh Hoyt, j...@janrain.com , JanRain Initial Editors * Dirk Balfanz, balf...@google.com, Google * Breno de Medeiros, br...@google.com, Google ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: RECOMMENDED: Proposal to create the Contract Exchange Extension working group
And the proposal... (i) WG name Contract Exchange Extension Working Group (ii) Purpose The purpose of this WG is to produce a standard OpenID extension to the OpenID Authentication protocol that enables arbitrary parties to create and exchange a mutually-digitally-signed contract. This contract can be both broadband and mobile friendly through appropriate bindings that will be defined for each use case. (iii) Scope Development of a specification that allows parties to exchange a mutually-digitally-signed contract leveraging on OpenID Authentication 2.0 and OpenID Attribute Exchange 2.0 via the appropriate bindings defined in the specification. Out of scope * UI and user experience: The Working Group will develop the wire protocol and and any related processing mechanisms required to support it but user interface and experience is out of scope. * Public Key Discovery method: This functionality will be either defined in the XRD 1.0 specification currently in progress at the OASIS XRI TC or a mechanism that works with OpenID Authentication 2.0/2.1 discovery will be defined independently. * Terms negotiation: Actual negotiation of the terms of a contract should be dealt with out-of-band or by other specifications. * Assurance: These will be handled by third-party assurance programs or other identity governance frameworks. * Trust hierarchies. It is the intent that this specification be usable by any trust community, whether it uses conventional PKI hierarchies, peer-to-peer trust mechanisms, reputation systems, or other forms of trust assurance. The specification of any particular trust root, trust hierarchy, or trust policy is explicitly out of scope. (iv) Proposed List of Specifications * Contract Exchange 1.0 - Expected completion of the first iteration is in Q1 2009. (v) Anticipated audience or users of the work Implementers of OpenID Providers and Relying Parties, especially those who require security and accountability features to exchange sensitive customer information (e.g. personally identifiable information and credit card numbers) responsibly among trusted parties. (vi) Language in which the WG will conduct business English. (vii) Method of work E-mail discussions on the working group mailing list, working group conference calls, and possibly face-to-face meetings at conferences. (viii) Basis for determining when the work of the WG is completed Drafts will be evaluated on the basis of whether they increase or decrease consensus within the working group. The work will be completed once it is apparent that maximal consensus on the drafts has been achieved, consistent with the purpose and scope. (b) Background Information. (i) Related work being done by other WGs or organizations * OpenID Authentication 2.1 [AN] * OpenID Attribute Exchange Extension 2.0 [AX] * LIberty Alliance Identity Governance Framework [IGF] 1.0 Draft * XML Advanced Electronic Signatures [XAdES] * WS-Trust 1.3 [WS-trust] * XRI 2.0 and XRI 3.0 [XRI] * XRD 1.0 [XRI] * XDI 1.0 [XDI] * Vendor Relationship Management [VRM] (ii) Proposers * Drummond Reed, =drummond, drummond.r...@parity.com, Cordance/Parity/OASIS (U.S.A) * Henrik Biering, h...@netamia.com, Netamia (Denmark) * Hideki Nara, hd...@ic-tact.co.jp, Tact Communications (Japan) * John Bradeley, jbrad...@mac.com, OASIS IDTrust Member Section (Canada) * Mike Graves, mgra...@janrain.com, JanRain, Inc. (U.S.A.) * Nat Sakimura, n-sakim...@nri.co.jp, Nomura Research Institute, Ltd.(Japan) * Robert Ott, robert@clavid.com, Clavid (Switzerland) * Tatsuki Sakushima, tats...@nri.com, NRI America, Inc. (U.S.A.) * Toru Yamaguchi, try...@gmail.com, DeNA Co. Ltd. (Japan) Editors: Nat Sakimura, n-sakim...@nri.co.jp, Nomura Research Institute, Ltd. (iii) Anticipated Contributions * Sakimura, N., et. al OpenID Trusted data eXchange Extention Specification (draft), Oct. 2008. [TX2008]. - David Recordon da...@sixapart.com wrote: The Specifications Council recommends that the Foundation members approve the creation of the Contract Exchange Extension working group (http://openid.net/pipermail/specs-council/2009-January/000110.html), as proposed below and found at http://wiki.openid.net/Working_Groups%3AContract_Exchange_1. If you are a member of the OpenID Foundation, you'll be able to login and vote on the creation of this new working group after this 14-day notice period. The vote thus will be from Wednesday Saturday 14th through Saturday February 21st. All votes are held in US Pacific Time. --David ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Request for consideration of AX 2.0 Working Group Charter Proposal
This has been on my list to kick to the specs council but I've also been waiting for Dick to reengage since he's been such a core driver of the AX spec in the past. :) --David - Nat Sakimura sakim...@gmail.com wrote: On Sat, Jan 24, 2009 at 4:02 AM, Breno de Medeiros br...@google.com wrote: Unfortunately, not much to report except that most appear to agree in your last suggestion, which I parse as: Allow type.alias = type_schema_url to define a 'type namespace'. Within that namespace it would then be possible to create an extensible schema based on plain string key-value pairs. We need to: 1. Get the blessing of specs council to form a WG. I believe we have addressed all concerns raised in threads in the Wiki proposal and I am not sure why I have not heard from specs council back. How do we call for a vote on the WG formation? Right. I will kick the specs council for this one also. The board is aware that specs council has not been effective and starting to fix it. (There will be a board voting to start the ammendment to the OpenID process shortly.) Guys, please raise your voices also from the community side. Dick, I think you still are a spec council member, so please start pinging other specs council members from inside. Process-wise, there are four more steps involved in startgin this WG. 1) Specs council's recommendation 2) Membership vote to form WG. 3) Contributors submitting IPR agreements for this WG. 4) OIDF to provide the post restricted ML and SVN repository for the WG. Additionally, it would be good if OIDF could supply write controlled wiki just like OASIS Open does. 2. Start writing this spec, in particular hash out the parts that are in agreement so that people can start cranking on this. :) Yes! On Fri, Jan 23, 2009 at 10:54 AM, Dick Hardt dick.ha...@gmail.com wrote: Hey Everyone I dropped off the planet for a bit moving and getting my world setup. Have missed all the email threads on this. What have I missed out on? :-) I plan on participating heavy in the AX 2.0 spec myself. -- Dick On Tue, Dec 23, 2008 at 12:12 PM, Allen Tom a...@yahoo-inc.com wrote: I believe that one of the goals of AX 2.0 should be to maintain backwards compatible with AX 1.0 whenever possible. Allen Mike Jones wrote: Can you add a clear statement to the draft charter that implementations already using AX 1.0 will remain compatible with the output of this working group? Or is backwards-compatibility with existing AX implementations not a goal of this work? -- Mike -Original Message- From: specs-boun...@openid.net [mailto: specs-boun...@openid.net ] On Behalf Of Breno de Medeiros Sent: Thursday, December 18, 2008 6:18 PM To: OpenID Specs Mailing List Cc: d...@skip.com ; hd...@ic-tact.co.jp ; mgra...@janrain.com Subject: Request for consideration of Working Group Charter Proposal I would like to submit the following proposal for a new Working Group charter to your consideration, following the OpenID IPR process: The proposal charter is also available at: http://wiki.openid.net/Working_Groups:AX_2.0 OpenID Attribute Exchange 2.0 Working Group (AX 2.0) Charter Proposal In accordance with the OpenID Foundation IPR policies and procedures this note proposes the formation of a new working group chartered to produce an OpenID specification. As per Section 4.1 of the Policies, the proposed charter is below (still liable to change during this feedback period). I. Name Attribute Exchange Extension Working Group (AX) II. Statement of Purpose Produce an updated version of the Attribute Exchange Extension. III. Scope Update the Attribute Exchange Extension to include support for identified needs. Currently identified needs: * Provide mechanisms for RP to require, and the OP to assert, claims about the quality of the attributes. * Create an extensible registry of claim types, such as axschema.org for attribute types. The registry should also provide non-normative guidance on how claims can be validated, which will depend on the nature of attribute type as well as claim type. * Introduce a new request/response mode which, unlike fetch and store, allows for both transmittal of some values and request of others. The transmittal not necessarily has the significance of a store request (could be informative, or for requesting validation). * Introduce a direct communication method in both directions (OP-RP), supported via discovery, for bulk exchange of attributes about (potentially) multiple users. IV. Specifications OpenID Attribute Exchange 2.0 V. Anticipated audience
Re: OpenID Problem
Hi Faisal, While this is most likely a permissions issue between PHP and your filesystem, I doubt that you'll receive an answer on this mailing list. The specs@openid.net mailing list is designed to discuss the OpenID specifications themselves. You can try reposting to gene...@openid.net though might have more luck on the d...@lists.openidenabled.com mailing list which you can find at http://lists.openidenabled.com/mailman/listinfo/dev. --David - Faisal Rehman faisalrehma...@yahoo.com wrote: Hi, I have download openid library from here http://www.openidenabled.com/php-openid/ and i am facing problem how to use the given example. The Error i am facing is Could not create the FileStore directory '/tmp'. Please check the effective permissions. Even in my ini.php the value of open_basedir /var/www/vhosts/super-phone.com/httpdocs:/tmp:/tftpboot and master value for this is set as no value. tmp folder is in httpdocs have permission 777 but this is still giving this error i dont know why. and i am setting $store_path = /tmp in common.php please helpme i will be very thankfull to you. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Separation of Discovery from AuthN (was Proposal to form Discovery Working Group)
I'd advocate for waiting until all of the discovery work occurring in OASIS, IETF, and W3C shakes out before we make changes to how OpenID discovery works. I'd much rather make this sort of change once rather than twice. --David On Jan 4, 2009, at 11:14 PM, Drummond Reed wrote: I’m just catching up on holiday mail and wanted to add another +1 to separation of Discovery from AuthN. The sooner the better… =Drummond From: specs-boun...@openid.net [mailto:specs-boun...@openid.net] On Behalf Of David Fuelling Sent: Friday, December 26, 2008 8:47 AM To: Nat Sakimura Cc: John Bradley; specs@openid.net Subject: Re: Proposal to form Discovery Working Group On Thu, Dec 25, 2008 at 10:56 AM, Nat Sakimura n- sakim...@nri.co.jp wrote: 2. Separation of OP into Discovery Service and Authentication Service. In the current terminology, OP spans both Discovery Service and Authentication Service. We should be explicit about it. +1. I would like to see discovery services separated from OP services too. John Bradley wrote: Breno, I agree. I recommended separating discovery into a separate doc for 2.1. There didn't seem to be support for the idea at the time, perhaps circumstances have changed and the idea will be accepted now. Regards John Bradley =jbradley ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Proposal to form Discovery Working Group
Agreed with Breno here. We're going to have to make a change to OpenID discovery at some point over the next year as other groups finish their evolutions of Yadis, XRDS, etc. I like this being a separate WG since it means that the core Auth spec can choose to move to using it at a later date versus being tied up on it's development. --David On Dec 20, 2008, at 12:48 AM, Breno de Medeiros wrote: It is part of the scope of this group to develop a best-practices guidance for transition from YADIS to XRD discovery. Full backward-compatibility is not a goal, since at least one new mechanism for publishing discovery information is expected to make part of XRD discovery (dynamic mapping type), and this new mechanism is being put there (in XRD discovery) in large part because the current YADIS mechanism makes it difficult for smaller sites to become OPs/RPs by using a hosted solution (so it is an OpenID-driven need for wider adoption). XRD discovery is also expected to include a signing mechanism, which will allow for use of higher-security discovery profiles. As part of this best-practices document, the OpenID discovery spec should give guidance on the security characteristics of each profile. The current mechanism (which limits re-directs and enforces realm authority = return_to url authority) will constitute a profile and there will likely be at least a second profile that verifies signatures on the discovered documents but allow for unmatched realm/return_to URLs. That being said, we are certainly aware of the need to make the transition as smooth as possible, and that is why it is part of the scope of this group to write a transitions guidance document. On Fri, Dec 19, 2008 at 11:28 PM, Mike Jones michael.jo...@microsoft.com wrote: Can you add a clear statement to the draft charter that implementations already using Yadis will remain compatible with the output of this working group, since, as I understand it, XRDS- Simple is intended to be compatible with Yadis? Or is backwards- compatibility with existing OpenID 2.0 implementations not a goal of this work? -- Mike -Original Message- From: specs-boun...@openid.net [mailto:specs-boun...@openid.net] On Behalf Of Breno de Medeiros Sent: Thursday, December 18, 2008 6:14 PM To: OpenID Specs Mailing List Cc: David Recordon; Brian Eaton; Johannes Ernst Subject: Proposal to form Working Group I would like to submit the following proposal for a working group charter (also available at http://wiki.openid.net/Working_Groups:Discovery): Services and Metadata Discovery Coordination Working Group (Discovery) Charter Proposal In accordance with the OpenID Foundation IPR policies and procedures this note proposes the formation of a new working group chartered to produce an OpenID specification. As per Section 4.1 of the Policies, the proposed charter is below (still liable to change during this feedback period). I. Name Services and Metadata Discovery Coordination Working Group (Discovery) II. Statement of Purpose Produce a document describing the OpenID discovery workflow, updating the current mechanism to describe how to use OASIS specifications for discovery, to be drafted by the OASIS XRI TC. The intention is that the document will be incorporated as part of some future version of the OpenID Authentication spec. III. Scope Produce a document describing the use of OASIS discovery specifications as formulated by the OASIS XRI TC, for normative application by all other OpenID specifications. Produce a document describing the recommended migration of services discovery from the Yadis 1.0 specification to the discovery specifications currently being developed by the OASIS XRI TC. All types of identifiers addressed by OASIS XRI TC discovery (XRD 1.0) are within scope of this WG. Publish a list of service and resource types supported by the discovery mechanism. IV. Specifications OpenID Discovery, including a sub-spec for Trusted OpenID Discovery, and a best-practices guidance document for migration. V. Anticipated audience All those interested in the OpenID specifications. VI. Language of business English. VII. Method of work Mailing list discussion. Posting of intermediate drafts in the OpenID Wiki. Virtual conferencing on an ad-hoc basis. VIII. Basis for completion of the activity The discovery document is final and all deliverables have been incorporated into the OpenID Authentication spec, perhaps by reference. Background Information I. Related Work XRD 1.0 spec, being drafted by the OASIS XRI TC. II. Initial Membership * Brian Eaton, bea...@google.com, Google, Inc. * Johannes Ernst, jer...@netmesh.us, NetMesh. (editor) * Eran Hammer-Lahav, e...@hueniverse.com, Yahoo! Inc. * Breno de Medeiros, br...@google.com, Google, Inc. (editor) * David Recordon, da
Re: Proposal to form Discovery Working Group
Can you please put it on http://wiki.openid.net/Working_Groups%3AOpenID_Discovery? Thanks, --David On Dec 22, 2008, at 11:08 AM, Breno de Medeiros wrote: BTW, the discovery WG proposal does not appear in the new version of the wiki. On Mon, Dec 22, 2008 at 11:07 AM, Breno de Medeiros br...@google.com wrote: For the time being, I would be happy if the 2.1 spec moved all the references to discovery to a second document. The first version of the separate document would just clone the current approach to discovery in the 2.0 spec. If the updated version that explains XRD discovery is available before the 2.1 WG completes its work, then it could refer to the new document, otherwise it could refer to the old document. In the case of pointing to old document, we probably should add an appendix noting that changes in discovery to support new use cases are coming, and pointers on how to manage the transition. On Mon, Dec 22, 2008 at 10:27 AM, David Recordon drecor...@sixapart.com wrote: Agreed with Breno here. We're going to have to make a change to OpenID discovery at some point over the next year as other groups finish their evolutions of Yadis, XRDS, etc. I like this being a separate WG since it means that the core Auth spec can choose to move to using it at a later date versus being tied up on it's development. --David On Dec 20, 2008, at 12:48 AM, Breno de Medeiros wrote: It is part of the scope of this group to develop a best-practices guidance for transition from YADIS to XRD discovery. Full backward-compatibility is not a goal, since at least one new mechanism for publishing discovery information is expected to make part of XRD discovery (dynamic mapping type), and this new mechanism is being put there (in XRD discovery) in large part because the current YADIS mechanism makes it difficult for smaller sites to become OPs/RPs by using a hosted solution (so it is an OpenID-driven need for wider adoption). XRD discovery is also expected to include a signing mechanism, which will allow for use of higher-security discovery profiles. As part of this best-practices document, the OpenID discovery spec should give guidance on the security characteristics of each profile. The current mechanism (which limits re-directs and enforces realm authority = return_to url authority) will constitute a profile and there will likely be at least a second profile that verifies signatures on the discovered documents but allow for unmatched realm/return_to URLs. That being said, we are certainly aware of the need to make the transition as smooth as possible, and that is why it is part of the scope of this group to write a transitions guidance document. On Fri, Dec 19, 2008 at 11:28 PM, Mike Jones michael.jo...@microsoft.com wrote: Can you add a clear statement to the draft charter that implementations already using Yadis will remain compatible with the output of this working group, since, as I understand it, XRDS-Simple is intended to be compatible with Yadis? Or is backwards-compatibility with existing OpenID 2.0 implementations not a goal of this work? -- Mike -Original Message- From: specs-boun...@openid.net [mailto:specs-boun...@openid.net] On Behalf Of Breno de Medeiros Sent: Thursday, December 18, 2008 6:14 PM To: OpenID Specs Mailing List Cc: David Recordon; Brian Eaton; Johannes Ernst Subject: Proposal to form Working Group I would like to submit the following proposal for a working group charter (also available at http://wiki.openid.net/Working_Groups:Discovery): Services and Metadata Discovery Coordination Working Group (Discovery) Charter Proposal In accordance with the OpenID Foundation IPR policies and procedures this note proposes the formation of a new working group chartered to produce an OpenID specification. As per Section 4.1 of the Policies, the proposed charter is below (still liable to change during this feedback period). I. Name Services and Metadata Discovery Coordination Working Group (Discovery) II. Statement of Purpose Produce a document describing the OpenID discovery workflow, updating the current mechanism to describe how to use OASIS specifications for discovery, to be drafted by the OASIS XRI TC. The intention is that the document will be incorporated as part of some future version of the OpenID Authentication spec. III. Scope Produce a document describing the use of OASIS discovery specifications as formulated by the OASIS XRI TC, for normative application by all other OpenID specifications. Produce a document describing the recommended migration of services discovery from the Yadis 1.0 specification to the discovery specifications currently being developed by the OASIS XRI TC. All types of identifiers addressed by OASIS XRI TC discovery (XRD 1.0) are within
A Working Groups Wiki Page
We now have a wiki page for Working Groups! http://wiki.openid.net/Working_Groups I've listed the current PAPE WG as well as the groups that I know have been proposed. I've also filled in the draft charter for the Auth 2.1 group at http://wiki.openid.net/Working_Groups:Auth_2.1. If you're wanting to see a WG happen, please take this time to fill in it's draft charter so that members of this list can review it. My goal would be to have all four of the proposed groups ready to be voted on by the Foundation Membership during the same period as the Board election -- one week from today -- so that they can all be created within the next two weeks. If you need help writing a charter, I'm happy to help. --David ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Proposal to create the TX working group
) Related work being done by other WGs or organizations: OpenID Attribute Exchange Extension 1.0 [AX] LIberty Alliance Identity Governance Framework [IGF] 1.0 Draft XML Advanced Electronic Signatures [XAdES] WS-Trust 1.3 [WS-trust] XRI 2.0 [XRI] XDI 1.0 [XDI] Vendor Relationship Management [VRM] (ii) Proposers: Drummond Reed, [EMAIL PROTECTED], Cordance/Parity/OASIS (U.S.A) Henrik Biering, [EMAIL PROTECTED], Netamia (Denmark) Hideki Nara, [EMAIL PROTECTED], Tact Communications (Japan) John Bradeley, [EMAIL PROTECTED], OASIS IDTrust Member Section (Canada) Mike Graves, [EMAIL PROTECTED], JanRain, Inc. (U.S.A.) Nat Sakimura, [EMAIL PROTECTED], Nomura Research Institute, Ltd.(Japan) Robert Ott, [EMAIL PROTECTED], Clavid (Switzerland) Tatsuki Sakushima, [EMAIL PROTECTED], NRI America, Ltd. (U.S.A.) Toru Yamaguchi, [EMAIL PROTECTED], Cybozu Lab (Japan) Editors: Nat Sakimura, [EMAIL PROTECTED], Nomura Research Institute, Ltd. (iii) Anticipated Contributions: * Sakimura, N., et. al OpenID Trusted data eXchange Extention Specification (draft), Oct. 2008. [TX2008]. On Wed, Nov 12, 2008 at 6:39 AM, David Recordon [EMAIL PROTECTED] wrote: Just wanted to add that Nat is running a session on TX at IIW this afternoon. We should definitly chat about the needs being expressed in this thread and how they might be able to be solved with OpenID. --David On Nov 11, 2008, at 1:13 PM, Martin Paljak wrote: On 09.11.2008, at 20:51, Nat Sakimura wrote: As to AX+SAML (or for that matter XAdES) is concerned, that is a valid approach, but if I were to use SAML, I would use Just to clarify a technical detail: The XAdES example regarding Estonia you mentioned earlier does not include transporting XAdES payloads over OpenID AX (which seems to be the purpose of the discussed workgroup where the similarities of SAML over AX come in). The special behavior and out of band assurances given by openid.ee does not include anything new on the protocol level, just added semantics to basic OpenID transactions. If we could use PDF signatures as legally valid signatures in Estonia, it could be PDF based signatures instead of XAdES, or ODF signatures, or MS .doc signatures. FYI, openid.ee allows a RP to upload a contract (template) which must be agreed with and digitally signed (legally binding signature resulting in an XAdES document with the filled in contract signed by the user with an ID-card and stored on the OP) before the OP starts issuing positive assertions about the given user to the given RP. The contract could be a document of any kind (PDF, JPG, DOC, TXT) and the only thing that is transferred to the RP over AX is a 'secret url' from where the RP can download the signed contract (XAdES container with the possibly PDF contract in it). The actual assurance (that the user has signed the contract the RP has uploaded) comes from out of band agreements/contracts between OP and RP. The AX attribute is just an extra option, if the RP wishes to automatically fetch and store the signed contract somewhere. Basically it is an advanced and legally binding 'I agree with terms and conditions' checkbox built on top of standard OpenID. With legally binding I mean that it is dead simple in the court: Here are the terms and conditions you digitally signed and which you have violated as checking checkboxes and pressing 'continue' is not a legally binding action in Estonia, at least I don't know of any court cases about it. If you need an example use case, think of signing and faxing NDA-s before you can download some simple secret product documentation. -- Martin Paljak http://martin.paljak.pri.ee +372.515.6495 -- Nat Sakimura (=nat) http://www.sakimura.org/en/ -- Nat Sakimura (=nat) http://www.sakimura.org/en/ ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: PAPE and NIST level policies.
Yeah, the latest draft is at http://openid.net/specs/openid-provider-authentication-policy-extension-1_0-05.html . On Nov 25, 2008, at 2:21 AM, Martin Paljak wrote: Right. I was lazy and google directed me to 1.0-02 as the first response ... m. On 25.11.2008, at 12:03, Nat wrote: The proposal on the table has generalized NIST thing, I believe. As to the upstream hint is concerned, I think it is a good idea but it was out of scope of the current WG. It belongs to the future spec I guess. [EMAIL PROTECTED] via iPhone On 2008/11/25, at 18:10, Martin Paljak [EMAIL PROTECTED] wrote: Hi. PAPE responses have the ability to send NIST levels used for authentication. It would be useful to add these levels as standardized request policy URLs to the spec so that the RP could send hints on wished authentication strength to the OP. BTW, why is there a specific nist_auth_level parameter which is directly tied to one standards institute yet the 'core' of PAPE, policies, don't really define anything except vague 'policies to be specified elsewhere' ? -- Martin Paljak http://martin.paljak.pri.ee +372.515.6495 ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs -- Martin Paljak http://martin.paljak.pri.ee +372.515.6495 ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Proposing an OpenID Authentication 2.1 Working Group
Yep, thanks! I'll be sending out a new charter shortly. On Nov 11, 2008, at 11:24 AM, George Fletcher wrote: Great notes! Thanks! Martin Atkins wrote: Here's the output from today's IIW session on this: 2.0 has been finalized bunch of implementations found lots of spec bugs also gone and done oauth and email addresses and other things. Can we support these in the core spec? - Making the spec more readable and fixing bugs (eratta) - Delegation - Error handling - Adding a security appendix - could be a separate document referred to by the spec - possibly produced by separate group - Who controls this security page? - Security committee could look after this. - or Allen at Yahoo! will be editing a security document - Clarifying XRI - Currently there's no firm message about whether RPs MUST support XRIs or not. - Need to clarify how exactly XRI should be used with OpenID. - Similar to the whitelist question. - Clarify if RPs can white or blacklist what OPs they accept, and vice-versa. - Discovery of type of identifiers an RP supports. - Clarifying IRI - Updating discovery. Possibly including the new-fangled XRD discovery. - Clarifying whether association over SSL must/can use diffie- hellman. - Discovery of support of checkid_immediate. Exploratory work: - Signature mechanisms. Looking at additionally supporting the mechanisms defined in OAuth so that they can be closer together. - Possibly deprecating the current signature mechanism. - Public keys? - Email-shaped identifiers for OpenID - Could be a separate working group? There was consensus that email-shaped identifiers would be worked on by a separate group and possibly rolled into 2.1 if it's done in time. - Smart/rich clients? - Could be in this WG unless it ends up being a big change in which case it could be its own WG. - There's another session about this. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs -- Chief Architect AIM: gffletch Identity Services Work: [EMAIL PROTECTED] AOL LLC Home: [EMAIL PROTECTED] Mobile: +1-703-462-3494 Office: +1-703-265-2544 Blog: http:// practicalid.blogspot.com ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Proposal to create the TX working group
Just wanted to add that Nat is running a session on TX at IIW this afternoon. We should definitly chat about the needs being expressed in this thread and how they might be able to be solved with OpenID. --David On Nov 11, 2008, at 1:13 PM, Martin Paljak wrote: On 09.11.2008, at 20:51, Nat Sakimura wrote: As to AX+SAML (or for that matter XAdES) is concerned, that is a valid approach, but if I were to use SAML, I would use Just to clarify a technical detail: The XAdES example regarding Estonia you mentioned earlier does not include transporting XAdES payloads over OpenID AX (which seems to be the purpose of the discussed workgroup where the similarities of SAML over AX come in). The special behavior and out of band assurances given by openid.ee does not include anything new on the protocol level, just added semantics to basic OpenID transactions. If we could use PDF signatures as legally valid signatures in Estonia, it could be PDF based signatures instead of XAdES, or ODF signatures, or MS .doc signatures. FYI, openid.ee allows a RP to upload a contract (template) which must be agreed with and digitally signed (legally binding signature resulting in an XAdES document with the filled in contract signed by the user with an ID-card and stored on the OP) before the OP starts issuing positive assertions about the given user to the given RP. The contract could be a document of any kind (PDF, JPG, DOC, TXT) and the only thing that is transferred to the RP over AX is a 'secret url' from where the RP can download the signed contract (XAdES container with the possibly PDF contract in it). The actual assurance (that the user has signed the contract the RP has uploaded) comes from out of band agreements/contracts between OP and RP. The AX attribute is just an extra option, if the RP wishes to automatically fetch and store the signed contract somewhere. Basically it is an advanced and legally binding 'I agree with terms and conditions' checkbox built on top of standard OpenID. With legally binding I mean that it is dead simple in the court: Here are the terms and conditions you digitally signed and which you have violated as checking checkboxes and pressing 'continue' is not a legally binding action in Estonia, at least I don't know of any court cases about it. If you need an example use case, think of signing and faxing NDA-s before you can download some simple secret product documentation. -- Martin Paljak http://martin.paljak.pri.ee +372.515.6495 ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Email Address to URL Transformation
Hey Arshad, This is now something we're talking about supporting in OpenID Authentication 2.1 though it isn't yet clear whether it will support a transformation technique like EAUT or something else. --David On Aug 12, 2008, at 5:35 PM, Arshad Khan wrote: Does OpenID 2.0 support ‘Email Address to URL Transformation (EAUT)? There is some info on this page of what EAUT is: http://blog.vidoop.com/archives/139 Has Vidoop developed this outside OpenID 2.0 framework? Thanks. Arshad ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Proposing an OpenID Authentication 2.1 Working Group
OpenID Authentication and OAuth Core. Both OpenID Authentication and OAuth Core share a similar protocol flow with similar HMAC style cryptographic signing. OAuth uses a slightly different and newer signing mechanism. Changing this in OpenID Authentication would break backwards compatibility, but the WG should explore the difference(s) and consider adding support for OAuth's mechanism alongside the current mechanism for forwards compatability. Anticipated Contributions: Specification text from a variety of contributors to achieve the goals listed in the above scope. Proposed List of Specifications: OpenID Authentication 2.1. Completion expected within the next six months. Anticipated audience or users of the work: Implementers of OpenID Providers and Relying Parties. Language in which the WG will conduct business: English. Method of work: E-mail discussions on the working group mailing list, working group conference calls, and possibly a face-to-face meeting at the Internet Identity Workshop. Basis for determining when the work of the WG is completed: Proposed changes will be evaluated on the basis of whether they increase or decrease consensus within the working group. The work will be completed once it is apparent that maximal consensus on the draft has been achieved, consistent with the purpose and scope. Proposers: - Allen Tom, [EMAIL PROTECTED], Yahoo! - Brad Fitzpatrick, [EMAIL PROTECTED], Google - Breno de Medeiros, [EMAIL PROTECTED], Google - Carl Howells, [EMAIL PROTECTED], JanRain - David Recordon, [EMAIL PROTECTED], Six Apart - Drummond Reed, [EMAIL PROTECTED], Parity/Cordance/OASIS - Gabe Wachob, [EMAIL PROTECTED] - Gary Krall, [EMAIL PROTECTED], VeriSign - John Bradley, [EMAIL PROTECTED] - Johnny Bufu, [EMAIL PROTECTED] - Joseph Smarr, [EMAIL PROTECTED], Plaxo - Josh Hoyt, [EMAIL PROTECTED], JanRain - Mart Atkins, [EMAIL PROTECTED], Six Apart - Max Engel, [EMAIL PROTECTED], MySpace - Scott Kveton, [EMAIL PROTECTED], Vidoop Initial Editors: - David Recordon, [EMAIL PROTECTED], Six Apart - John Bradley, [EMAIL PROTECTED] ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Proposal to create the OpenID OAuth Hybrid Working Group
I see this as being really needed and quite a bunch of work has already gone into the doc. I'm wondering if it would be better to write a Scope which describes the work and list the current draft as an Anticipated Contribution rather than just saw that the Scope is to standardize that document. Cheers, --David On Nov 3, 2008, at 2:33 AM, Yariv Adan wrote: In accordance with the OpenID Foundation IPR policies and procedureshttp://openid.net/foundation/intellectual-property/ this note proposes the formation of a new working group chartered to produce an OpenID specification. As per Section 4.1 of the Policies, the specifics of the proposed working group are: Background Information: OpenID has always been focused on how to enable user-authentication within the browser. Over the last year, OAuth has been developed to allow authorization either from within a browser, desktop software, or mobile devices. Obviously there has been interest in using OpenID and OAuth together allowing a user to share their identity as well as grant a Relying Party access to an OAuth protected resource in a single step. A small group of people have been working on developing an extension to OpenID which makes this possible in a collaborative fashion withinhttp://code.google.com/p/step2/. This small project includes a draft spec and Open Source implementations which the proposers would like to finalize within the OpenID Foundation. Working Group Name: OpenID OAuth Hybrid Working Group Purpose: Produce a standard OpenID extension to the OpenID Authentication protocol that provides a mechanism to embed an OAuth approval request into an OpenID authentication request to permit combined user approval. The extension addresses the use case where the OpenID Provider and OAuth Service Provider are the same service. To provide good user experience, it is important to present a combined authentication and authorization screen for the two protocols. Scope: Standardize the draft Hybrid Protocol (http://step2.googlecode.com/svn/spec/openid_oauth_extension/drafts/0/openid_oauth_extension.html ) as an official OpenID Extension describing how to combine an OpenID authentication request with the approval of an OAuth request token. Anticipated Contributions: Draft specification referenced above and various text contributions as more developers implement it. Proposed List of Specifications: OpenID OAuth Extension 1.0. Spec completion by Q4 2008. Anticipated audience or users of the work: - OpenID Providers and Relying Parties - OAuth Consumers and Service Providers - Implementers of OpenID Providers and Relying Parties Language in which the WG will conduct business: English. Method of work: E-mail discussions on the working group mailing list and working group conference calls. Basis for determining when the work of the WG is completed: The work will be completed once it is apparent that maximal consensus on the protocol proposal has been achieved within the working group, consistent with the purpose and scope. Proposers: - Ben Laurie, [EMAIL PROTECTED], Google - Breno de Medeiros, [EMAIL PROTECTED], Google - David Recordon, [EMAIL PROTECTED], Six Apart - Dirk Balfanz, [EMAIL PROTECTED], Google - Joseph Smarr, [EMAIL PROTECTED], Plaxo - Yariv Adan, [EMAIL PROTECTED], Google - Allen Tom, [EMAIL PROTECTED] , Yahoo - Josh Hoyt, [EMAIL PROTECTED] , JanRain Initial Editors: - Dirk Balfanz, [EMAIL PROTECTED], Google - Breno de Medeiros, [EMAIL PROTECTED], Google -- Yariv Adan | Product Manager Google Switzerland GmbH | Identifikationsnummer: CH-020.4.028.116-1 This e-mail is confidential. If you are not the right addressee please do not forward it, please inform the sender, and please erase this e-mail including any attachments. Thanks. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Proposal to create the TX working group
After reading the extension a few times, I'm getting caught up in 4.1.6 (http://svn.sourceforge.jp/cgi-bin/viewcvs.cgi/*checkout*/spec/openid-trust-exchange-1_0.html?root=openidtx#anchor7 ) which references amounts being paid, currency, contracts, terms of the contract, etc. Overall, I'm pretty confused about what this extension does (it seems to do a lot of different things) which is making it hard for me to determine a better name. I also still feel that the reuse of AX (for it's extensibility) combined with the ability to exchange signed SAML tokens is a more future proof method and something that will be easier to be widely adopted as OpenID continues to evolve. --David On Nov 8, 2008, at 11:14 PM, Drummond Reed wrote: +1. “OpenID Trust Extension” seems like a good fit. =Drummond From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nat Sakimura Sent: Saturday, November 08, 2008 12:22 PM To: [EMAIL PROTECTED] Cc: specs@openid.net Subject: Re: Proposal to create the TX working group Maybe just OpenID Trust Extension just like WS-Trust? =nat On Sun, Nov 9, 2008 at 5:06 AM, Nat Sakimura [EMAIL PROTECTED] wrote: Hi David, I do not have any particular attachment to trust exchange. So, I am ok in changing it but it would be nice if I can preserve TX acronym though. Do you have any specific suggestions? =nat On Sun, Nov 9, 2008 at 3:50 AM, David Recordon [EMAIL PROTECTED] wrote: Hi Nat, Thanks. I still would really like to see the name changed for when we think about the World-wide market. Do others disagree? OpenID Trust Exchange just feels like it doesn't actually describe what the spec does nor how you can actually exchange trust. --David On Nov 1, 2008, at 2:19 AM, Nat Sakimura wrote: Hi David, Thanks for your comments. My reply inline below: 2008/11/1 David Recordon [EMAIL PROTECTED] Hey Nat, Do you see this as being built atop Attribute Exchange for transport or as something new that TX defines? I know Sxip had done work with AX to enable passing signed and encrypted attributes using SAML assertions. I have thought of using AX as transport once, then gave up on it when I was thinking of a mobile use case where the amount of payload that could be carried with was very limited (URL length in GET is limited to one of 128bytes, 256bytes or 512bytes depending on the handset). So, the current draft looks a lot like AX with bunch of hard coded attribute types in a way. As far as carrying SAML token etc. in AX are concerned, similar thing has also been done by one of the proposer, Robert Ott of Clavid. Martin Paljak of Estonia (openid.ee) has been using XAdES with AX. These approach are valid. However, I thought the approach partly defeats the purpose of OpenID. If we were using SAML, then we could have used it through out. I wanted to make it easier for the developers by sticking to the tag- value approach. This made us define some of the attribute types defined in SAML and XAdES to be defined as tag-value tag. Is Trust Exchange really the best name? Seems like trust is quite a broad concept so something more specific might be better. Right. Naming was a bit problematic. I started using Trust because the messaging model is not dis-similar to WS-Trust. Now, the trust defined in WS-Trust in our context is essentially Contract. So I thought of changing it to CX or something, but then, at least in Japan, quite a few key people were already exposed to TX by now and thus I kept the name TX. --David On Oct 31, 2008, at 4:21 AM, Nat Sakimura wrote: Dear Specification Council members: In accordance with the OpenID Foundation IPR policies and procedures this note proposes the formation of a new working group chartered to produce an OpenID specification. As per Section 4.1 of the Policies, the specifics of the proposed working group are: Trust Exchange (TX) Extension WG Charter In accordance with the OpenID Foundation IPR policies and procedures this note proposes the formation of a new working group chartered to produce an OpenID specification. As per Section 4.1 of the Policies, the specifics of the proposed working group are: Proposal: (a) Charter. (i) WG name: Trust Exchange Extension (TX) (ii) Purpose: The purpose of this WG is to produce a standard OpenID extension to the OpenID Authentication protocol that enablesarbitrary parties to create and exchange a mutually- digitally-signed legally binding contract. This protocol extension aims to be both broadband and mobile friendly by defining appropriate bindings for each use case. Although this specification defines one default protocol for transfering data based on the contract, the data transfer portion is intended to be pluggable so that other protocols may also be used for this purpose. The extension is not intended to be a general method for defining attributes; the scope is limited
Fwd: [xrds-simple] Refocusing XRDS / XRDS-Simple / Discovery
This is worth reading as it outlines what Eran plans to do with the current XRDS and XRDS-Simple specifications. It will have future implications on OpenID as the current Yadis discovery protocol actually violates the HTTP and web architecture (as pointed out by the W3C). I'm going to be following this work and figure a future version of OpenID should make use of it. That will mean that OPs will likely need to support the new discovery mechanism while also supporting the current one for a period of time as it becomes deprecated. cc'ing Eran in case there are questions, but the discussion is occuring on the XRDS Simple list at http://groups.google.com/group/xrds-simple for the time being. --David Begin forwarded message: From: Eran Hammer-Lahav [EMAIL PROTECTED] Date: October 27, 2008 3:06:41 PM PDT To: [EMAIL PROTECTED] [EMAIL PROTECTED] Subject: [xrds-simple] Refocusing XRDS / XRDS-Simple / Discovery Reply-To: [EMAIL PROTECTED] I have been reviewing XRDS and XRDS-Simple for the past couple of months, including their relationship to HTTP, web architecture, and most importantly, the use cases that are driving the development of an HTTP discovery protocol. What I am most interested in has always been a protocol for discovering metadata about an HTTP resource. This metadata is focused on two things: the resource itself, and its relationship to other resources. Brand / Document Type I would like to change focus from XRDS/XRDS-Simple to XRD. XRDS as a sequence of XRD elements is specific to XRI resolution where the sequence of XRDs adds value. The inclusion of multiple XRD elements does not fit within the model of a document describing a resource. My proposed use of URI fragment together with xml:id attributes ads much complexity and little value and will be dropped. I propose to name this specification ‘XRD: Extensible Resource Descriptor’. There is existing value in the XRDS and XRDS-Simple brands, but it is extremely low outside the social-web/identity echo- chamber. Pushing out a somewhat new brand of XRD with a simple acronym (Extensible Resource Descriptor) goes a long way in delivering our message. Focusing on the application/xrd+xml and XRD schema will also make the transition easier as there will be less overlap in headers, elements, and existing documents. By offering an XRD-top-level document, there is less chance of conflicting with existing XRI and OpenID documents. This effort should be branded as XRD 1.0. XRDS is currently in version 2.0 (which failed an OASIS vote) and is now planned to become 3.0. I think that for branding purposes, starting with version 3.0 is counterproductive, but I do not have strong opinions in the version number. One idea I like is to drop the version and use a date instead (common for W3C standards). Another advantage of keeping XRDS XRI-specific is that the current XRDS element not included in the new XRD schema will be able to get assigned to the XRDS namespace which will prevent the need to define a third namespace just for XRI-specific elements (on top of the XRDS and XRD namespaces). Venue / Namespace XRD is a product of the OASIS XRI TC and if for no other reason than to give proper attribution, should stay anchored there. I intend to draft and publish the XRD specification as a product of the XRI TC and will be joining OASIS in the next few days. As an OASIS standard, the XRD schema should have an OASIS http namespace (http://docs.oasis-open.org/ns/xri/xrd/1.0 or http://docs.oasis-open.org/ns/xri/xrd/2008/11). However, much of the relevant community to a generic HTTP discovery mechanism and resource metadata resides in the IETF where HTTP is defined and evolved. I would like to find a way to publish OASIS drafts simultaneously as IETF I-Ds for informational purposes only. At the end, I would like to see the OASIS standard assigned an IETF RFC number. Again, this is not a proposal for standardization at the IETF, just using the RFC as a publication channel. This proposal needs much discussion by the XRI TC and would ultimately be their decision. Discovery Workflow The entire discovery workflow defined by Yadis will be replaced in XRD. Support for the ‘Accept’ HTTP header will be removed as it violates HTTP and web architecture. The direct-access use case (of accessing the metadata document without interacting with the resource itself) will be supported using the new /site-meta proposal [1] with a dynamic map to transform the resource URI to the metadata URI. The resource metadata map functionality will be added to the next draft of the /site-meta proposal or published as a separate proposal. The plan is to add support for mapping between a resource’s URI to the URI of its metadata document by using a URI template. Currently, the draft only covers links to site-wide metadata. However, there are use cases in which
Re: Proposal to create the TX working group
Hey Nat, Do you see this as being built atop Attribute Exchange for transport or as something new that TX defines? I know Sxip had done work with AX to enable passing signed and encrypted attributes using SAML assertions. Is Trust Exchange really the best name? Seems like trust is quite a broad concept so something more specific might be better. --David On Oct 31, 2008, at 4:21 AM, Nat Sakimura wrote: Dear Specification Council members: In accordance with the OpenID Foundation IPR policies and procedures this note proposes the formation of a new working group chartered to produce an OpenID specification. As per Section 4.1 of the Policies, the specifics of the proposed working group are: Trust Exchange (TX) Extension WG Charter In accordance with the OpenID Foundation IPR policies and procedures this note proposes the formation of a new working group chartered to produce an OpenID specification. As per Section 4.1 of the Policies, the specifics of the proposed working group are: Proposal: (a) Charter. (i) WG name: Trust Exchange Extension (TX) (ii) Purpose: The purpose of this WG is to produce a standard OpenID extension to the OpenID Authentication protocol that enables arbitrary parties to create and exchange a mutually-digitally-signed legally binding contract. This protocol extension aims to be both broadband and mobile friendly by defining appropriate bindings for each use case. Although this specification defines one default protocol for transfering data based on the contract, the data transfer portion is intended to be pluggable so that other protocols may also be used for this purpose. The extension is not intended to be a general method for defining attributes; the scope is limited to a specific set of attributes necessary for contract semantics. The extension will also define a contract signature based on public key cryptography. When used with a digital certificate signed by a third party, the contract and signature can be used as an assertion of conformance to an applicable assurance program. (iii) Scope: Scope of the work Development of the specification including: An extensible tag-value contract format Public Key Cryptography based digital signature method applied to the above contract format Query/response communication protocols for establishing the contract Default data transfer protocol based on the contract Conformance requirements for other data transfer protocol bindings Security, threats and Risk analysis Perform Security Risk analysis and profiles for best practice Out of scope Term negotiation: Actual negotiation of the terms of a contract should be dealt with out-of-band or by other specifications. General purpose data type identifiers: this should be determined on a per-community bases using other specifications such as OpenID Attribute Exchange. Assurance programs or other identity governance frameworks. It is the intent that this specification be usable by any trust community, whether it uses conventional PKI hierarchies, peer-to- peer trust mechanisms, reputation systems, or other forms of trust assurance. The specification of any particular trust root, trust hierarchy, or trust policy is explicitly out of scope. (iv) Proposed List of Specifications: TX 1.0, spec completion expected in January 2009. (v) Anticipated audience or users of the work: Implementers of OpenID Providers and Relying Parties, especially those who require security and accountability features to exchange sensitive customer information (e.g. personally identifiable information and credit card numbers) responsibly among trusted parties. (vi) Language in which the WG will conduct business: English. (vii) Method of work: E-mail discussions on the working group mailing list, working group conference calls, and possibly face-to- face meetings at conferences. (viii) Basis for determining when the work of the WG is completed: Draft 1 will be evaluated on the basis of whether they increase or decrease consensus within the working group. The work will be completed once it is apparent that maximal consensus on the draft has been achieved, consistent with the purpose and scope. (b) Background Information. (i) Related work being done by other WGs or organizations: LIberty Alliance Identity Governance Framework (IGF) 1.0 Draft XML Advanced Electronic Signatures (XAdES) (ii) Proposers: Drummond Reed, [EMAIL PROTECTED], Cordance/Parity/OASIS (U.S.A) Henrik Biering, [EMAIL PROTECTED], Netamia (Denmark) Hideki Nara, [EMAIL PROTECTED], Tact Communications (Japan) John Bradeley, [EMAIL PROTECTED], OASIS IDTrust Member Section (Canada) Mike Graves, [EMAIL PROTECTED], JanRain, Inc. (U.S.A.) Nat Sakimura, [EMAIL PROTECTED], Nomura Research Institute, Ltd.(Japan) Robert Ott, [EMAIL PROTECTED], Clavid (Switzerland) Tatsuki Sakushima,
Re: [OpenID] Problems with OpenID and TAG httpRange-14
I don't see why changes would really need to wait, if there is an interested group of people then lets spin up a mailing list and get participants to agree to the IP policy. The entire goal of having working groups and seperate mailing lists is to help ensure that future OpenID specs are not encumbered with intellectual property issues. The easiest, and most common, way to do this is creating seperate technical working mailing lists based around related topics or a specification. This allows people to choose where they wish to participate since the requirement of posting to one of these lists is agreeing that your contributions are being made under the OpenID IPR Policy. This list (specs@openid.net) is a great place to identity issues that need addressing and figuring out who wants to work on solving them. Once that happens, I have no problem helping to make it legit so that the resulting spec is good from an IP perspective. --David On Mar 10, 2008, at 12:46 PM, Drummond Reed wrote: -Original Message- From: Noah Slater [mailto:[EMAIL PROTECTED] Sent: Monday, March 10, 2008 1:43 AM To: Drummond Reed Cc: specs@openid.net Subject: Re: [OpenID] Problems with OpenID and TAG httpRange-14 Noah, you are in the right place (and the General list is the wrong place, which is why I have removed that cc). Okay, thank you. Once those groups start, they will each have dedicated mailing lists. In the meantime, this is the list for discussing any spec issues. So far one OpenID Authentication 2.0 editor, Johnny Bufu, has commented on the thread you started. Im a little confused about what this means. Does this mean that this issue will not get properly looked at until such time as the new WGs have been set up? It doesn't mean it won't get looked at or discussed here. However any formal changes to the specifications must wait until these WGs are started. Is there anywhere further to go from here? No, this is the right place, and until the WGs are started, any discussion should take place on this list. I'll bring it up at the next OpenID Foundation board meeting (this Thursday) so board members are aware of this issue. =Drummond ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: handling of url redirection
Hi Marv, This has never been specified as a relying party could choose to follow as many redirects as it wishes. Maybe there should be a hard line drawn though from an interoperability side? --David On Feb 17, 2008, at 3:06 PM, SignpostMarv Martin wrote: Was talking with keturn in #openid , and it seems that the spec currently doesn't indicate how 30x redirects should be handled. More specifically, how deep an OpenID-enabled application should follow redirects before giving up. ~ Marv ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OpenID 3.0
+1. Let's get 2.0 deployed and figure out what it might be lacking before just starting on 3.0. On Feb 3, 2008, at 11:05 PM, Johannes Ernst wrote: Amen. Let's build (optional) extensions, and only if that absolutely does not work for an essential feature, meekly suggest that the smallest possible set of changes be made to an existing spec. Note that any term such as OpenID 3.0 is mostly a marketing / branding term, just like OpenID 2.0. What it really means is what underlying specs are being packaged into a larger term. On Feb 2, 2008, at 2:36, Martin Atkins wrote: I apologise that this message doesn't directly address any of the points you've made, but others have been doing that. I just want to make a general point: In my opinion, we should resist the urge to start specing OpenID 3.0 (aka OpenID vNext) and try to do everything else that needs to be done with extensions now. OpenID 2.0 has laid the framework for decentralized extensibility, so it should now be much easier to work within that framework. If it turns out that some particular feature absolutely can't be done without making a new Authentication spec release then so be it, but ideally I think we want 2.0 to be stable for many years to come to avoid repeating all of the current pain of incompatible versions and the poor user experience that creates. McGovern, James F (HTSC, IT) wrote: Figured I would ask if anyone is interested in brainstorming the next version of OpenID and how it can be used in Enterprise B2B settings and not solely focusing on consumerish interactions. Some things that I would like to see in the next version are: 1. A discussion on how AuthZ can converge with OpenID 2. Modeling of relationships 3. Not allowing an OpenID to be a vector for SQL Injection and putting something around what it should look like 4. A way to indicate to the relying party what level of authentication has occurred such as did the OP check a password, how did it validate a user. Without this, there is no way that a trust model could be established in a credible way. 5. A way for OpenID relying parties to filter out Ops. In a business scenario, if I run the Sun employee store, I may only want the Sun OP to talk with me. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OAuth + OpenID
Great, thanks! We're talking about these drawing at OpenIDDevCamp right now. Thanks, --David On Dec 11, 2007, at 7:33 PM, NISHITANI Masaki wrote: I enumerated all possible cases to use OAuth and OpenID together to organize my thought a bit more. And correct the charts for one misunderstanding. In cahrt 3, there should be another user-interaction phase for SP, which behaves as a relying party in OpenID context, to obtain user identifier. I will be grad with any comment to this. Possible cases to use OAuth and OpenID together. 1. Consumer, SP and OP all differ (4-entity case) 1.1 Both of Consumer and SP does not use OpenID at all. - This is just a simple OAuth usecase (chart 1). 1.2 Consumer requires OpenID authentication, SP does not. - Same as simple OAuth except place OpenID transactions before initiating OAuth (above all chart 1 sequence). 1.3 SP requires OpenID authentication, Consumer does not. - Chart 3. 1.4 Both requires OpenID authentication. - Almost same as chart 3. Just place another OpenID sequences above all of lines. 2. Consumer and SP are same. Does not need to use OAuth. 3. SP and OP are same. 3.1 Consumer does not use OpenID. - Simple OAuth. 3.2 Consumer does use OpenID. - Sequences are just same in chart 3, or possibly optimize like chart 4. 4. Consumer and OP are same. 4.1 SP does not use OpenID - Sinple OAuth. 4.2 SP uses OpenID - This is a bit strange case. It is possible to use OpenID authentication for SP, but it is meaningless. OAuth aims to data exchange without desclosing user credentials and in this case, consumer already knows user credential because it is a OpenID provider itself. 5. All same. Surprisingly, does not need OpenID nor OAuth. Let me call this ``plain old web service'' ;-P Hi all. According to the theme, OAuth and OpenID, talked in the IIW 2007b, I have made up a brief diagrams for a sort of self-brainstorming. It is a shame for me not have been able to join in that session in IIW, though regarding the wiki page placed at http://iiw.idcommons.net/index.php/OAuth_and_OpenID , it went over mainly about a case of SP (it's an OAuth term) and OP (OpenID term) are same one. Now the diagrams consists of - Page 1; Ordinary OAuth sequence chart. Page 2; Same for OpenID. Page 3; Using OAuth and OpenID together, Consumer does not need authorization but access to user's data stored in SP, and SP uses OpenID for its authorization method. Page 4; Superimposing OAuth and OpenID, SP and OP are same one and consumer requires user's data stored in OP/SP and uses OpenID as well. This is a starting point for me and now I am looking for any other use case and trying to make myself clear. Probably there is some chances to make the protocols simpler. One case is to skip association phase using the Consumer secret or RSA key of the consumer to verify consumer/RP. I will be grad if I have comments. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs OpenID_OAuth_Chart.pdf___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Finalizing OpenID Authentication 2.0 and OpenID Attribute Exchange
Hey all, While its certainly been a long process in the making, it seems that we're now in a position to declare OpenID Authentication 2.0 and OpenID Attribute Exchange as final specifications. Both have evolved through extensive community participation and feedback and each are stable as Implementor Drafts for a number of months now. Both specifications are already shipping in some libraries and products including Google's Blogger (via Sxip's library) and Drupal who did their own implementation of the specification and multiple OpenID Providers with support for both of these specifications as well. Additionally the following libraries exist which implement OpenID Authentication 1.1 and 2.0, OpenID Attribute Exchange, and OpenID Simple Registration 1.0: - http://code.sxip.com/openid4java/ - Java OpenID library from Sxip - http://code.google.com/p/joid/ - Java OpenID library from Verisign - http://framework.zend.com/fisheye/browse/Zend_Framework/trunk/library/Zend/OpenId - http://OpenIDEnabled.com/ - PHP, Python, and Ruby libraries As part of the IPR work over the past few months we've begun collecting non-assertion agreements from contributors to both of these specifications. These agreements are a way for contributors (and others) to these specifications to formally declare that they will not assert any patent rights against OpenID implementations. The majority of them are in and the goal is to have any remaining in by the Internet Identity Workshop this coming Monday through Wednesday. When this happens we'll be creating a page on OpenID.net so that everyone can find the various agreements as well as copies of them that have been signed. As soon as all of the non-assertion agreements are in, I very strongly +1 making these two specifications final to be announced at IIW this coming week. Cool? Cool! --David ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: [security] Phishing-Resistant Authentication definition
Do you have proposed wording for this? It might also make sense to rename this policy to something like No Shared Secret and then also draft a second policy which allows shared secrets which are more resistant to phishing than passwords. In the end, not calling anything phishing resistant may be beneficial to resolving everyone's concerns. Thanks, --David On Nov 20, 2007, at 1:32 PM, Dick Hardt wrote: Recently this definition of Phishing-Resistant Authentication was proposed: · Phishing-Resistant Authentication An authentication mechanism where the End User does not provide shared secrets to a party potentially under the control of the Relying Party that could enable that party to then authenticate elsewhere as if it were the End User. (Note that the potentially malicious Relying Party controls where the User-Agent is redirected to and thus may not send it to the End User's actual OpenID Provider). Given the rise of nasty MITM malware, I hope that we all agree that PAPE is not intended to protect the user from malware on their own machine, but to protect the user from malicious websites. If so, would it make sense to enhance the definition to reflect this? -- Dick ___ security mailing list [EMAIL PROTECTED] http://openid.net/mailman/listinfo/security ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Fwd: OSIS PAPE call results
Hey all, It turned out that from the OSIS interoperability event in Barcelona a call was scheduled to discuss PAPE issues from the interop. I heard about the call a few minutes before, but Mike, Johnny, and I had a really productive call. If no one disagrees, we should get these edits into the spec and release draft 3. Thanks, --David Begin forwarded message: From: Mike Jones [EMAIL PROTECTED] Date: November 1, 2007 10:04:02 PM GMT+01:00 To: [EMAIL PROTECTED] [EMAIL PROTECTED], Johnny Bufu [EMAIL PROTECTED] , [EMAIL PROTECTED] [EMAIL PROTECTED] Subject: OSIS PAPE call results Today we held the call discussing OSIS feedback on the PAPE spec. Topics covered and recommendations made on the call were: - Authorization decisions should be made solely by the relying party. The identity provider should accurately report the status of all policies requested by the relying party that the authentication complies with and may also choose to report the status of any policies that apply that were not explicitly requested. The policies are not mutually exclusive and no relationship between the different policies should be implied. A clarification to this effect should be added to the draft. - There was a request for a definition of Active Authentication as used in the auth_time element description. Intuitively, this involves at least having the user being at the machine as a participant in the authentication interaction in some manner. We agreed that we should look for an existing definition of active authentication that appears to apply. - The table in Appendix A.1.1 of http://openid.net/specs/openid-provider-authentication-policy-extension-1_0-02.html needs to be updated to be consistent with the definition in Section 4. Specifically: PIN and soft OTP token should not be marked as phishing- resistant. PIN and hard OTP token should not be marked as phishing- resistant. Information Cards should be added and listed as phishing- resistant. Active password managers that only release the password to the correct site should be listed as phishing-resistant. - If relying parties and OPs want to communicate actual authentication methods used, that should happen via a different spec than PAPE. Then the market can decide whether to use PAPE, this spec, both, or neither. (However some in the group have both privacy concerns about this and concerns about enabling attackers by giving them additional information to use in their attacks.) Finally, while we failed to discuss this on the call, I also believe that: PIN and digital certificate via HTTPS is phishable if the same certificate value is released to every site. PIN and digital certificate via HTTPS is not phishable if a different certificate value is released to every site. and that the table should be updated accordingly in this case as well. Someone who's an expert in this method should pipe in and provide guidance. Thanks all! -- Mike ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Some PAPE Wording Clarifications
I see both sides of this. At the end of the day the RP is ultimately making the decision as to if the user can proceed or not. Just as in SREG if the RP says email is required and the user/OP choose not to provide it, the RP still has to decide what to do. I do agree that it is easier on a RP to not have to understand any relationships between policies. In this case of the three defined policies I see that as less important, but the argument that it becomes increasingly likely that the RP may not understand a given policy created by an OP is quite legit. Also as you argue, the OP knows what actually happened so can best place that within the policies. I'm alright changing the recommendation to the OP at least including the specific policies requested by the RP and shifting some of that burden back to the OP. That also is in line with general OpenID philosophy of making the OP do the heavy lifting. Barry, I was talking to you about this yesterday, you alright with this as well? In any-case, lets get Draft 2 out in the next 2-3 hours. Thanks, --David On Oct 23, 2007, at 10:05 AM, Johnny Bufu wrote: + [...] For example it is recommended that if the OP +specified the Multi-Factor Physical Authentication policy and the RP +requested the Multi-Factor Authentication policy, that the RP's +requirements were met. This puts undue requirements on the RP implementations. As a design principle, I believe the goals were to make required effort and adoption and as easy as possible for RPs, and have more happening on the OP where possible. I would at least complement, if not replace, this patch with: For example, if the RP requested Multi-Factor and the OP supports Multi-Factor Physical, it is recommended that the OP includes both policies in the response. As I argued on the osis list, the OP is in the best position to make judgments about the qualities of its authentication mechanisms, and it should respond to the point to the RP's requests. What if the RP knows what Multi-Factor means, but has no idea (and no interest) in Multi-Factor-Physical? Johnny ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Some PAPE Wording Clarifications
Cool, committed. http://svn.openid.net/diff.php?repname=specificationspath=% 2Fprovider_authentication_policy_extension%2F1.0%2Ftrunk%2Fopenid- provider-authentication-policy-extension-1_0.xmlrev=378sc=1 We ready to publish Draft 2? --David On Oct 23, 2007, at 2:46 PM, Barry Ferg wrote: Yes, there are arguments to be made for both sides here. I have to agree with Johnny and David's point on this; lets give the RP what it can be reasonably expected to understand. On 10/23/07, David Recordon [EMAIL PROTECTED] wrote: I see both sides of this. At the end of the day the RP is ultimately making the decision as to if the user can proceed or not. Just as in SREG if the RP says email is required and the user/OP choose not to provide it, the RP still has to decide what to do. I do agree that it is easier on a RP to not have to understand any relationships between policies. In this case of the three defined policies I see that as less important, but the argument that it becomes increasingly likely that the RP may not understand a given policy created by an OP is quite legit. Also as you argue, the OP knows what actually happened so can best place that within the policies. I'm alright changing the recommendation to the OP at least including the specific policies requested by the RP and shifting some of that burden back to the OP. That also is in line with general OpenID philosophy of making the OP do the heavy lifting. Barry, I was talking to you about this yesterday, you alright with this as well? In any-case, lets get Draft 2 out in the next 2-3 hours. Thanks, --David On Oct 23, 2007, at 10:05 AM, Johnny Bufu wrote: + [...] For example it is recommended that if the OP +specified the Multi-Factor Physical Authentication policy and the RP +requested the Multi-Factor Authentication policy, that the RP's +requirements were met. This puts undue requirements on the RP implementations. As a design principle, I believe the goals were to make required effort and adoption and as easy as possible for RPs, and have more happening on the OP where possible. I would at least complement, if not replace, this patch with: For example, if the RP requested Multi-Factor and the OP supports Multi-Factor Physical, it is recommended that the OP includes both policies in the response. As I argued on the osis list, the OP is in the best position to make judgments about the qualities of its authentication mechanisms, and it should respond to the point to the RP's requests. What if the RP knows what Multi-Factor means, but has no idea (and no interest) in Multi-Factor-Physical? Johnny ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Fwd: [OpenID] Provider Assertion Policy Extension Draft 2 Published
Begin forwarded message: From: David Recordon [EMAIL PROTECTED] Date: October 23, 2007 4:39:23 PM PDT To: OpenID List [EMAIL PROTECTED] Subject: [OpenID] Provider Assertion Policy Extension Draft 2 Published Reply-To: [EMAIL PROTECTED] Hey all, Draft 2 of PAPE has now been published. http://openid.net/2007/10/23/ provider-asserton-policy-extension-draft-2/ Cheers, --David ___ general mailing list [EMAIL PROTECTED] http://openid.net/mailman/listinfo/general ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
An OAuth OpenID Extension
Hey all, I know John did some work in September (http://extremeswank.com/ openid_trusted_auth.html and http://extremeswank.com/ openid_inline_auth.html). Both solve extremely important use-cases and are becoming increasingly discussed especially with the advent of OAuth. I'd really like to see how we can work to write an extension to OpenID Authentication where the OpenID Provider is also the one handling OAuth credentials. This would be useful in the inline authentication use case as well as if we move to a deployment scenario where the OAuth Provider is checking with the user's OpenID Provider to verify OAuth signatures. Overtime I also think moving OpenID to the OAuth signature mechanism would be beneficial, but I think that is a longer conversation. --David ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Defining PAPE active authentication (WAS: Re: PAPE Extension Specification)
Agreed with Jonathan here, don't think we need to define a policy URI for active. Rather need to clarify what is meant in section 5.1. (Optional) If the End User has not actively authenticated to the OP within the number of seconds specified in a manner fitting the requested policies, the OP MUST authenticate the End User for this request. What about? Active authentication is defined as the user providing a credential to the OP beyond a cookie which passively stores prior authentication credentials. Still don't like that definition, but hopefully a few iterations and we'll get there. Also asking around in the security community if there is a definition for this. --David On Oct 11, 2007, at 9:33 AM, Johnny Bufu wrote: On 8-Oct-07, at 4:56 PM, Jonathan Daugherty wrote: # Yep, the idea is for the PAPE spec to define a few generic and # agreed upon policies and then RPs and OPs can create others. Thus # if there isn't agreement on a policy, there would be multiple policy # URIs. Same concept as in Attribute Exchange. Using policy URIs to indicate certain modes of authentication is a fine idea, but that doesn't really address the original issue: the spec does not define active (direct) authentication. Agreed. PAPE spec should define one such policy that's acceptable for most of the OPs/RPs (and tie auth_age to it), leaving the possibility open for anyone to define other similar policies. This could be a bit tricky to specify if there's another parameter involved, but we should be able to come up with a solution. Johnny ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: PAPE Extension Specification (part 2)
On Oct 9, 2007, at 10:08 AM, Jonathan Daugherty wrote: Hi all, Here are a few more items. Section 5.1 - The spec doesn't specify what should be done in the absence of max_auth_age in a PAPE request. I could assume, but it would be easy enough to specify, say, that the OP is to authenticate the user at its own discretion. Works for me. http://svn.openid.net/diff.php? repname=specificationspath=% 2Fprovider_authentication_policy_extension%2F1.0%2Ftrunk%2Fopenid- provider-authentication-policy-extension-1_0.xmlrev=372sc=1 - In my opinion, the third paragraph for max_auth_age (beginning The OP should realize) is implicit. I think it should be removed. I could be convinced either way. Personally I lean toward leaving it since it provides additional context as to the parameter. All of PAPE is a negotiation dance between the RP and OP, so also inferring that a RP may or may not choose to deny access to the user is important. - The preferred_auth_policies specification claims, If multiple policies are requested, the OP SHALL try to satisfy as many as it can. In terms of language strength, SHALL try is an oxymoron. Can we change this to If multiple policies are requested, the OP SHOULD satisfy as many as possible? Good catch. http://svn.openid.net/diff.php? repname=specificationspath=% 2Fprovider_authentication_policy_extension%2F1.0%2Ftrunk%2Fopenid- provider-authentication-policy-extension-1_0.xmlrev=372sc=1 - The preferred_auth_policies specification also states that If no policies are requested, the RP is interested in other information such as the authentication age. I think that is speculative and should be removed. If it isn't removed, I think it should be moved to a section discussing the protocol flow more generally. I've moved it down under the Value: line which is where most other notes are. If there is somewhere else to put it entirely that is good too. Been trying to augment the parameters with a note so that it is easy to get context all in one place. http://svn.openid.net/ diff.php?repname=specificationspath=% 2Fprovider_authentication_policy_extension%2F1.0%2Ftrunk%2Fopenid- provider-authentication-policy-extension-1_0.xmlrev=374sc=1 Thanks, --David Thanks, -- Jonathan Daugherty JanRain, Inc. irc.freenode.net: cygnus in #openid cygnus.myopenid.com ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Question about PAPE
Hey Siddharth, Just to be clear, a OTP hardware token is considered a one-time password device token not a Hard token given SP 800-63, section 6 on page 15. This means that a OTP device can satisfy up to level 3, though a FIPS compliant Hard token would be needed for level 4. Level 3 also requires two-factor authentication, so OTP plus at least a password or pin. On page 37, it gives the example of a one-time password device combined with a Level 1 password transmitted via TLS. When replying with a NIST level, the OP can only include one value. Thus if 0, 1, 2 and 3 are possible, the OP should decide which level it wishes to respond with. While 3 may be the strongest, there may be situations where you instead want to respond with a lower values. Yes, per the PAPE abstract it does not talk about enrollment or identity proofing. --David On Oct 12, 2007, at 3:36 PM, Bajaj, Siddharth wrote: Hi David, I have a quick question about the PAPE draft specification. In the response parameters, you can set a parameter called 'openid.pape.nist_auth_level' There is a section 7.1.2 that describes the paramter and in the last table the spec maps some of the common authentication technologies to the NIST levels. Now for example, lets take an OTP hardware token, which satisfies the requirements for Levels 1, 2, and 3. So, should the OP set the value of the parameter to the highest level that it satisfies (in this case 3) or does the OP individually list all the auth levels it meets (in this case 1,2,3). This is not clear From the table or the spec. Given that the barcelona interop is coming up, can you clarify. Also, the NIST levels typically take into account the authentication credential as well as id proofing. I'm guessing that for the purposes of PAPE we are ignoring the initial ID vetting/id proofing requirements. Thanks, Siddharth ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Defining PAPE active authentication (WAS: Re: PAPE Extension Specification)
Hey Paul, How do you guys define passive. Seems like the opposite problem of defining active. Thanks, --David On Oct 22, 2007, at 3:18 PM, Paul Madsen wrote: SAML 2.0 expresses it in terms of whether or not the authentication is 'passive' paul David Recordon wrote: Agreed with Jonathan here, don't think we need to define a policy URI for active. Rather need to clarify what is meant in section 5.1. (Optional) If the End User has not actively authenticated to the OP within the number of seconds specified in a manner fitting the requested policies, the OP MUST authenticate the End User for this request. What about? Active authentication is defined as the user providing a credential to the OP beyond a cookie which passively stores prior authentication credentials. Still don't like that definition, but hopefully a few iterations and we'll get there. Also asking around in the security community if there is a definition for this. --David On Oct 11, 2007, at 9:33 AM, Johnny Bufu wrote: On 8-Oct-07, at 4:56 PM, Jonathan Daugherty wrote: # Yep, the idea is for the PAPE spec to define a few generic and # agreed upon policies and then RPs and OPs can create others. Thus # if there isn't agreement on a policy, there would be multiple policy # URIs. Same concept as in Attribute Exchange. Using policy URIs to indicate certain modes of authentication is a fine idea, but that doesn't really address the original issue: the spec does not define active (direct) authentication. Agreed. PAPE spec should define one such policy that's acceptable for most of the OPs/RPs (and tie auth_age to it), leaving the possibility open for anyone to define other similar policies. This could be a bit tricky to specify if there's another parameter involved, but we should be able to come up with a solution. Johnny ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs -- Paul Madsen e:paulmadsen @ ntt-at.com NTT p:613-482-0432 m:613-282-8647 aim:PaulMdsn5 web:connectid.blogspot.com ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Some PAPE Wording Clarifications
Hey Johnny and Jonathan, Just checked in some clarifications, review would be appreciated. http://openid.net/pipermail/commits/2007-October/000381.html Thanks, --David ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
SVN URLs Changed
Hey all, We're currently in the process of changing all of the SVN URLs to be in the form of http://svn.openid.net/. New URLs are: http://svn.openid.net/ - WebSVN http://svn.openid.net/repos/website/ http://svn.openid.net/repos/specifications/ Sorry for the change, --David ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
HTML-Based Discovery with OP Identifiers
Sitting here in Seattle with Drummond and looking through the spec. Section 7.3.3 says: HTML-based discovery MUST be supported by Relying Parties. HTML- based discovery is only usable for discovery of Claimed Identifiers. OP Identifiers must be XRIs or URLs that support XRDS discovery. That is a bit confusing to parse so we were looking at re-wording it. Issue is Claimed Identifier is defined as possibly being a User-Supplied Identifier which in turn can be an OP Identifier thus making this paragraph fall apart. This then brought up the question of why can't HTML-Based Discovery be used for OP Identifiers? So the reason here is that the link elements don't actually describe the protocol version, rather the OP Endpoint URL and OP-Local Identifier. This thus presented us with the problem of how do we version these elements; which we did via openid. vs openid2.. Does it actually make more sense to add a new link element for the protocol version? This means we don't need the kludgey openid2.x as well as allows support for OP Identifiers. Thus we could have: link rel=openid.provider href=OP Endpoint URL / link rel=openid.ns href=http://openid.net/server/2.0; / -or- link rel=openid.provider href=OP Endpoint URL / link rel=openid.ns href=http://openid.net/signon/2.0; / So a parallel to the openid.ns parameter within the messages themselves. Thoughts? --David (and Drummond too) sending from gmail since VPN won't connect :-\ ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
