I'm getting now into WG comments, rather than last call issues. So feel free to scorn me.
2.1 makes it clear that metadata SHALL be used to select OP based on their support for the RP's authentication "policies". Given the YADIS model (n different copies of the user's metadata exist as resources located at different URLs, only some of which may be under the formal security policy control of an OP), a user with n metadata files each with 1 authentication policy can be signaling his/her requirements/limits on a given RP.
2.1 implies that an RP may refuse, by local means, to proceed with OpenID Auth if the metadata contains authentication policies that do not intersect with the RP's requirements.
2.5 is not clear whether the process of verifying additional confirmations (to use the precise SAML term, precisely) is an OpenID Auth process (possibly in a per-vendor extension), or a local process.
2.1-2.5 imply that an OP may ignore the RP-requested authentication policy.
3. the term policies should be replaced by Authentication Policies, if that is what is intended. This whole section is far too vague, as written. Suddenly a new URI is introduced for use in the XRDS metadata, which may or may not refer to instances under the per-message namespace URI. It seems to tie back to the URI use in the definition of Authentication Policy, however.
The definition of Authentication Policy is vague. I cannot tell if a prior agreement (a) is required between any 1 OP any 1 RP in existence (b) is required between the specific OP and RP engaged in an OpenID Auth run (c) refers to the URI choice or the policy denoted by the URI.
Harking back to 2.5, the final use of policy, omitting the qualifier authentication (and thus not using a defined term) makes me wonder if the control is specifically being scoped to signal the need to address other policy issues. (i.e. how pedantic a reading do I need to make?)
4. the first use of should ought to be may, given the semantics defined earlier concerning the Rp's requested authentication policy signal
5.1 the MUST phrasing makes it sound like the PAPE extension is now mandatory for any use of OpenID Auth. This may not be what is intended.
Concerning openid.pape.max_auth_age, change to "the OP SHOULD actively authenticate the End User for this request." noting insertion of actively. "The OP should realize that not adhering" is not good writing. The definition of SHOULD addresses these issues, without muddying the semantics of SHOULD. In any case, the sudden introduction of the notion of re-authentication (note re) should be avoided. Stick with active authentication throughout, which may or may not imply re-authenticaiton. (does re-authentication mean previousSession... referring to the traditional SAML bugbear).
Concerning openid.pape.preferred_auth_policies, the semantics suddenly change from may to SHOULD (note capitals): as in "Zero or more authentication policy URIs that the OP SHOULD". Earlier text defines a MAY condition ("When multiple policies are listed in the Relying Party's request, it is up to the OpenID Provider to satisfy as many of the policies as it can"). Secondly, formally one cannot conform to a "URI", but to the policy denoted by the URI. But, Im getting picky. Use of the verb conform itself is also not really warranted. Reserve conform/conforming for use in promoting interoperability, testing etc. Don’t overload it when discussing policy enforcement.
Concerning openid.pape.auth_level.ns.<cust>, I recommend adding examples: "The name space for the custom Assurance Level defined by various parties, such as a country, industry specific standards body, vendors or users." This makes it clear that its entirely legitimate for vendors and users to define authentication policy namespaces (and authentication policies). Or remove the examples. Technical standards really ought to stay out of asserting from legitimacy judgments for [authentication] policy authorities.
Concerning openid.pape.auth_level.ns... I now note we are suddenly back to talking about levels, not policies. So, Im confused. Is authentication level a [historical accident] synonym for authentication policy, or something actually different, now? Dont get all academically pedantic on us or get all defensive, here. Clarity is essential.
Concerning openid.pape.preferred_auth_level_types,and noting earlier Concerning openid.pape.preferred_auth_policies, its suddenly very clear that levels and policy are supposed to co-exist,and that a level is a critical control notion. Ive just no idea what is going on. But, then I really am dumb. I thought I knew from the document what were the core semantics and handling requirement concerning Authentication Policy signals. But, at this point I've really no idea about the semantics of authentication levels, and have no context on their handling requirements. I recommend the abstract introduces this distinction, very clearly. The current abstract only discusses authentication policy [claims].
Ok. Given all that , I cannot bring myself to comment in a detailed and careful manner on the rest. It was doing fine in general, until the last issue.
Peter.
-----Original Message-----
From: general-bounces@openid.net [mailto:general-bounces@openid.net] On Behalf Of Peter Williams
Sent: Thursday, October 09, 2008 2:58 AM
To: david@sixapart.com; Dick Hardt
Cc: OpenID List
Subject: Re: [OpenID] Building on the OpenID PAPE specification
I read it as saying
NIST ns is mandatory for 1.1, optional for 2.0.
There is inconsistency in the use of terms. At some points the text is specifying controls about authentication "policies", authentication "levels" (section 1.2) in others.
Or, it's actually correct. In that case, I don't understand some obviously very, very important subtlety. Given I'm pretty typically very dumb about web2.0 security models (which as a journalist once lectured me is all about "identity" not security) this would not be particularly surprising. Perhaps we are seeing a good example of how specifically identity2.0 semantics are being crafted - in a way that is subtly different to SAML's authnReq equivalents.
-----Original Message-----
From: general-bounces@openid.net [mailto:general-bounces@openid.net] On Behalf Of David Recordon
Sent: Thursday, October 09, 2008 1:13 AM
To: Dick Hardt
Cc: OpenID List
Subject: Re: [OpenID] Building on the OpenID PAPE specification
Hey Dick,
The current draft of the PAPE spec is at http://openid.net/specs/openid-provider-authentication-policy-extension-1_0-05.html
and as you said allows anyone to define policy URLs.
--David
On Oct 8, 2008, at 7:23 PM, Dick Hardt wrote:
>
> On 8-Oct-08, at 11:12 AM, Brian Kelly wrote:
>
>> Dick,
>>
>> I think it would be helpful to define the specific authentication
>> methods used as policies within PAPE. We could reduce the number of
>> authentication details in the current version of PAPE-AM and come up
>> with a list to be included as "authentication method URIs" in PAPE.
>> e.g.
>>
>> PKI algo: http://schemas.openid.net/pape/pki/rsa/1024
>> Private key storage:
>> http://schemas.openid.net/pape/pki/hardware-key-nonexportable
>> OTP: http://schemas.openid.net/pape/otp/hotp
>> Channel Security: http://schemas.openid.net/pape/channel/ssl_ev
>
> I have not seen the latest PAPE spec, but my understanding was that
> anyone could create a namespace that defines a policy. Nothing stops
> you from creating a namespace you think is important and promoting
> people to adopt it.
>
> Ideally PAPE would not define any of the policies, but the reality of
> adoption is you need to stick a stake in the ground to get it started.
> The mechanism allows OPs and RPs to use whatever makes sense.
>
>>
>>
>> To your second point, I would argue that not all OPs are created
>> equal. I see the OpenID landscape evolving into a variety of
>> "security levels" of OPs and RPs. Do I need an OP that requires a
>> hardware key to make a comment on a blog? No. But I do see the value
>> in having a "high security" OP to login to my bank account and
>> transfer money.
>
> I agree with you here wrt. different RPs will require OPs with
> different "security levels" -- the objective is to standardize those
> levels.
>
>>
>>
>> The need for more-secure OPs is evident by the lack of RP adoption on
>> commerce websites. These websites have more risk when it comes to
>> compromised accounts. RPs have the right to discriminate which OPs
>> they accept. And giving the RPs a framework with which to judge the
>> security of OPs should help _increase_ adoption of OpenID.
>
>
> Personally, I think more secure OPs is NOT the major barrier to RP
> adoption on commerce websites. Usability and protocol security are
> more significant in my opinion.
>
> -- Dick
>
> _______________________________________________
> general mailing list
> general@openid.net
> http://openid.net/mailman/listinfo/general
_______________________________________________
general mailing list
general@openid.net
http://openid.net/mailman/listinfo/general
_______________________________________________
general mailing list
general@openid.net
http://openid.net/mailman/listinfo/general
工具 
