OpenID Provider Authentication Policy Extension

[Recordon, David]

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: hans at granqvist.com [mailto:hans at granqvist.com] On Behalf Of Hans
Granqvist
Sent: Friday, June 22, 2007 3:50 PM
To: Recordon, David
Cc: specs at 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 <drecordon at verisign.com> 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 at openid.net
> http://openid.net/mailman/listinfo/specs
>