RE: OpenID Provider Authentication Policy Extension
Thanks, definitely am! Just catching up on a lot of email now. --David -Original Message- From: Johnny Bufu [mailto:[EMAIL PROTECTED] Sent: Friday, July 13, 2007 11:05 AM To: Recordon, David Cc: specs@openid.net Subject: Re: OpenID Provider Authentication Policy Extension David, On 22-Jun-07, at 9:46 AM, Recordon, David wrote: > So please, check it out and let me know what you think...especially > around the questions in the Editorial Comments section at the end. > > http://openid.net/specs/openid-provider-authentication-policy- > extension- > 1_0-01.html Hope you're still welcoming feedback on this.. While trying to explain what PAPE is/does, I noticed that the term 'authentication policy' is not explicitly defined in the spec (and how a policy differentiates from a specific authentication mechanism). A clear definition could help eliminate confusion between the two. Johnny ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: OpenID Provider Authentication Policy Extension
1) I imagine the URLs will become live at some point. :) 2) I wouldn't mind renaming it to "no-shared-secrets" which can also have a corresponding less secure policy of "shared-secret-second" or something like that which means the user provided a shared secret only after first providing something like a client side certificate. Also, the URLs are versioned (by date) which allows their definitions to evolve. 3) Like the http://schemas.openid.net/pape/policies/2007/06/none approach, it was required so a RP could tell the difference between a Provider not supporting the extension in the response versus not using any policies. 4) Yeah. Thanks, --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hans Granqvist Sent: Friday, June 22, 2007 3:50 PM To: Recordon, David Cc: specs@openid.net Subject: Re: OpenID Provider Authentication Policy Extension A few comments: * Would be great if all the namespace URLs resolved into live links. It always helps in the XML world and probably would in here too. * Section 4 Defined Authentication Policies We've talked about this before, but I just want to restate that it is a bad idea to name a policy based on its inferred values. "Phishing-resistant" implies a quality that is not necessarily measurable. Quality can also shift over time. The other policies are measurable (you can count number of factors used, for example). I'd strongly advise renaming "phishing-resistant" to something like "no-secrets-shared" (you can probably come up with a more succinct term) * 5.2 response params Requiring openid.pape.auth_policies to have a null value if no policies were met seems odd (and it may break processing where a value is always expected by the parser). Better would be to explicitly state that no policies were met by a predefined literal or URL. For example openid.pape.auth_policies=http://schemas.openid.net/pape/policies/2007/0 6/none * Section 7 Examples I wanted to see some examples on how PAPE is used in the messages. Maybe add a few? I like the work. However, the spec is optional. I was hoping finalizing auth 2.0 would be top priority. -Hans On 6/22/07, Recordon, David <[EMAIL PROTECTED]> wrote: > Over the past few weeks I've been working on the OpenID Provider > Authentication Policy Extension which is designed to replace the work I > did last year with the Assertion Quality Extension. > > Generally, the goal of this extension is to provide Relying Parties with > more information about how the End User authenticated to their Provider. > This is done by a mix of the RP requesting certain policies (such as > phishing-resistant or multi-factor), the OP helping the End User through > the authentication process, and then in the OpenID Authentication > response including the policies that were met as well as optionally a > strength level for the overall authentication. > > This extension doesn't speak at all toward trust of the End User or > Provider, so RPs will still have to decide if they believe the > information returned about the authentication in the response. > > So please, check it out and let me know what you think...especially > around the questions in the Editorial Comments section at the end. > > http://openid.net/specs/openid-provider-authentication-policy-extension- > 1_0-01.html > http://openid.net/specs/openid-provider-authentication-policy-extension- > 1_0-01.txt > > Thanks, > --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: OpenID Provider Authentication Policy Extension
5.1 1) Clarified. 2 & 3) Changed the MUST to a SHOULD, since the intent was never to restrict what a user could do. 4) Changed to "Integer" 5.2 1) What is the use-case for this? As the parameter always describes the policies returned in pape_auth_policies, the Provider should always know how long ago the user authenticated within the session. 2) I'm fine with time coming back instead of number of seconds. 3) Changed to integer. Thanks, --David -Original Message- From: Johnny Bufu [mailto:[EMAIL PROTECTED] Sent: Thursday, June 28, 2007 7:31 PM To: Recordon, David Cc: specs@openid.net Subject: Re: OpenID Provider Authentication Policy Extension David, On 22-Jun-07, at 9:46 AM, Recordon, David wrote: > So please, check it out and let me know what you think...especially > around the questions in the Editorial Comments section at the end. Here are the issues that came up while I implemented PAPE in openid4java: 5.1 Request Parameters - Is preferred_auth_policies REQUIRED? Assume yes, but not clearly spelled out. - "the OP MUST authenticate the End User for this request." What if the OP / user don't want to re-authenticate, and have reasons to continue their session with the previous / old auth? (For example user changed his mind at the OP about buying the book from amazon, and declines the OP's request to re-authenticate). - "The OP should realize that not adhering to the request for re- authentication..." implies there is an alternative to the above (other than breaking the protocol). Maybe the MUST above should be a SHOULD? - (max_)auth_age is defined as "numeric". Is there value for allowing floating-point numbers here? Would be simpler to be an integer. 5.2 Response Parameters - auth_age: What should the value be if the OP did not actively authenticate the user for the current session? Suggesting "unknown" as a special value for this. - auth_age: Since the message may spend a (not-insignificant) time after it's created (by the library) before it's put on the wire on the wire while it's being processed by the RP a timestamp value may be better suited here (rename it to auth_time maybe?). This way the RP will be able to determine the auth_age at any time (e.g. when it actually needs to perform the sensitive operation). Could use the formating used for nonces (from RFC3339). - nist_auth_level: "Numeric value" - probably was meant as integer value. Thanks, Johnny ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs