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/06/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
