Thoughts on Vidoop
Recently saw a demo of Vidoop and think there approach rocks. Was curious if there is an opportunity to express an authentication strength and style as an attribute to be consumed by the relying party. * This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies. * ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Some PAPE Wording Clarifications
+ [...] 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
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
RE: [OpenID] identify RP when it gets OpenID URL
I am keen for the RP to identify itself when it performs discovery – and I would love this feature to be in 2.0 before it is finalized. The proposal is very simple (to describe and to implement): RPs add a “From:” HTTP header field to HTTP requests made during the discovery phase. The underlying premise is that a user has many varied user-RP relationships, and it is easiest if the same OpenID URL can be used to access them all. The issue is how to support the varied relationships. Some OPs will support some variations, but no OP can support all possible variations (many are user-specific). Identifying the RP during discovery enhances the ability to choose the appropriate OP for a specific user-RP relationship. The need for this feature can be seen in the PAPE draft (§3 Advertising Supported Policies) and OpenID 2.0 draft (§12 Extensions). They support different OPs when authenticating to different RPs - but with very limited options, and with the RP in control of the choice. The user (via the server hosting their OpenID URL) should also be in control. http://openid.net/specs/openid-provider-authentication-policy-extension-1_0-02.html#advertising http://openid.net/specs/openid-authentication-2_0-12.html#extensions Both specify how a Yadis document can list multiple OPs, each associated with different OpenID protocol versions, understanding different OpenID extensions, and supporting different authentication policies. These details “aide in the process of a RP selecting which OP they wish to interact with”. The appropriate OP can only be chosen **by the RP** based on a very limited set of pre-defined xrd:Type URIs. When that works… great. When it doesn’t, the site hosting the OpenID URL should be able to choose the appropriate OP based on the RP’s identity. For that it needs the RP identity during discovery, hence the “From:” HTTP request header. Previously mentioned use cases: Alice wants to use a single OpenID URL and -- 1. She wants to use different OPs when logging in to different RPs. 2. An OP is not accessible to particular RPs (eg an internal company OP is not accessible by RPs on the Internet). 3. Different RPs whitelist different (non-overlapping) sets of OPs. 4. A particular RP requires PAPE support, which only Alice’s non-preferred OP supports. From: Manger, James H Sent: Wednesday, 17 October 2007 12:59 PM To: 'specs@openid.net' Subject: [OpenID] identify RP when it gets OpenID URL It can be useful to know who the Relying Party (RP) is during the discovery phase. That is, the RP should state their identify when they are looking up a user’s OpenID URL (Claimed Identifier). Use case: Alice wants to use different OPs for different RPs, while keeping the same URL (eg http://alice.example.net/). For instance, when logging into a service hosting her backups she wants to use an OP that requires a one-time password from a hardware token for each access. However, when leaving comments on blogs Alice wants to authenticate using an OP that only requires a password and uses a persistent cookie so she only has to log in once a day. Problem: Only one OP can be specified with a link rel=openid2.provider…/ element or in a Yadis document. [A Yadis document may be able to list many OPs, but I don’t think there is any mechanism for the RP to pick the right one.] Solution: The RP could include a From HTTP header when performing discovery. Instead of serving a static HTML page (or Yadis document) at http://alice.example.net/, the page could be dynamically generated based on the value of the From header. Suggested text for the authentication spec (draft 12): Add the following paragraph at the end of section 7.3 Discovery: “The Relying Party MUST include a From HTTP header field in each HTTP request made during discovery. The From field holds an email address for the RP (eg From: [EMAIL PROTECTED]) [RFC2616]. This enables the discovered information to vary based on the RP. The From field is not authenticated so it is not appropriate to use for access control.” Other solutions: The source IP address of the discovery request will often identify the RP, but this would be an unreliable mechanism due to proxies, clusters, load balancing, and changes at the RP. Separate user-supplied identifiers could be used, but that unnecessarily complicates the system for users. OPs can offer different authentication mechanisms based on the openid.return_to or openid.realm parameter in an authentication request. However, the user has less flexibility when they have to relying on OPs. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
