[OpenID board] More Uncertainty in IPR Process (Was: Fwd: [specs-pape] Feedback on PAPE 1.0 Draft 7)
David Recordon
drecordon at sixapart.com
Mon Dec 22 23:29:24 UTC 2008
This is a thread from the PAPE list showing another area where the IPR
Process needs more clarity. Mike and I are both interpreting wording
in two opposite ways.
--David
Begin forwarded message:
> From: Mike Jones <Michael.Jones at microsoft.com>
> Date: December 22, 2008 11:51:07 AM PST
> To: "david at sixapart.com" <david at sixapart.com>
> Cc: "specs-pape at openid.net" <specs-pape at openid.net>, Paul Madsen <paulmadsen at rogers.com
> >
> Subject: RE: [specs-pape] Feedback on PAPE 1.0 Draft 7
>
> Just as the passage you quoted says, working groups may recommend
> approval of any of the three types of specs: Implementer’s Draft,
> Final Specification, or Errata. It’s the working group’s choice
> whether to release a draft as an implementer’s draft – explicitly
> planning for another round of revision after implementation
> feedback, or a final draft, requiring revision only if feedback
> during the 60 days (including from implementations that occur during
> the 60 days). This working group has produced a final specification
> and recommended approval and the approval vote should commence today.
>
> --
> Mike
>
> From: specs-pape-bounces at openid.net [mailto:specs-pape-bounces at openid.net
> ] On Behalf Of David Recordon
> Sent: Monday, December 22, 2008 11:31 AM
> To: Mike Jones
> Cc: specs-pape at openid.net; Paul Madsen
> Subject: Re: [specs-pape] Feedback on PAPE 1.0 Draft 7
>
> I'm not sure that it actually is a misinterpretation. All sections
> talk about a draft becoming an Implementors Draft and then a Final
> Specification. Also read 5.5:
> 5.5 Final Approval. If there is consensus of, or a formal vote by,
> a WG to recommend approval of
> an Implementers Draft, Final Specification, or Errata, the
> applicable WG Editor(s) will notify the OIDF
> secretary, who will then post the applicable draft for review by the
> OIDF membership for a period of at least
> 45 days and notify the OIDF membership of the WG recommendation to
> approve and of the proposed dates
> on which the review period will end and the vote of the OIDF
> membership to accept or reject the WG
> recommendation will occur. The notice and vote will be in
> accordance with the specifications in Table 1, but
> the pre-vote notice may be concurrent with the last 14 days of the
> draft review period.
>
> On Dec 22, 2008, at 11:21 AM, Mike Jones wrote:
>
>
> No, this is a misinterpretation. It’s up to the working group
> whether to publish a draft specification as a final draft or an
> implementer’s draft. In this case, the working group went straight
> to a final specification. In both cases, the IPR processes provides
> IPR protection to implementers. For instance, because the working
> group declared draft 7 to be a final specification, for the last 60
> days implementers have had IPR protection, and could have given us
> comments based on their implementations. (None did.)
>
> BTW, I’m working on the approval vote, but there is a software bug
> I’m working with Refresh Media on that is preventing the poll from
> starting. Hopefully this will start today, as scheduled.
>
> --
> Mike
>
> From: David Recordon [mailto:drecordon at sixapart.com]
> Sent: Monday, December 22, 2008 11:04 AM
> To: Mike Jones
> Cc: specs-pape at openid.net; Paul Madsen
> Subject: Re: [specs-pape] Feedback on PAPE 1.0 Draft 7
>
> I think we've already broken the process quite a bit.
>
> 5.1 General. There are three stages of an OpenID Specification –
> draft, Implementers Draft, and
> Final Specification. An OpenID Specification begins as a “draft”
> and retains this status until approved as an
> Implementers Draft. An Implementers Draft may be further revised,
> and any revised Implementers Draft is
> deemed a “draft” until it is approved as a new Implementers Draft.
> The most recent Implementers Draft
> may be approved as a Final Specification.
>
> How I read this is that as we've not put out an Implementor's Draft
> (which has differnet IP impliciations than a Draft). This means
> that we still need to put out an Implementors Draft which has a 45
> day review period followed by a Final Specification with a 60 day
> period. I'm guessing what we just did was treat a Draft like a
> Final Specification. Thus if I'm reading the process correctly, we
> must release an Implementor's Draft and then a Final
> Specification. :-\
>
> --David
>
>
> On Dec 18, 2008, at 7:45 AM, Mike Jones wrote:
>
>
>
> I’ve just read through these comments in detail. I agree that
> incorporating most of these suggestions would clarify the document.
> However, I also agree with Paul that these are not showstoppers; in
> the language of the procedures document, these are not “critical
> comments or objections to approval”. The procedures also indicate
> that “No Substantive Change may be made to a Final Specification;
> any Substantive Change will require review and approval of a
> successor version of the applicable Final Specification according to
> these Processes.” Hence, if we make any of these clarifying
> changes, I believe it will restart the 60 day review period.
>
> Therefore, my recommendation is this: If any critical issues are
> identified during the review period that would cause us to change
> the draft, then we should absolutely also address Paul’s suggested
> clarifications. However if they are not, I believe that the
> community would be better served by prompt approval of the
> admittedly, somewhat imperfect, Draft 7 than by the creation and
> later approval of a Draft 8.
>
> Do others concur with this position?
>
> --
> Mike
>
> P.S. Paul, a few of your comments, such as suggested changes to
> protocol parameter names, would cause us to violate our charter, as
> we bound by the charter to maintain compatibility with Draft 2
> implementations, and so these could not be accepted.
>
> From: specs-pape-bounces at openid.net [mailto:specs-pape-bounces at openid.net
> ] On Behalf Of Paul Madsen
> Sent: Friday, December 05, 2008 9:55 AM
> To: specs-pape at openid.net
> Subject: [specs-pape] Feedback on PAPE 1.0 Draft 7
>
> Hi all, below are some comments (inline prefaced with PM ) on PAPE
> 1.0 Draft 7
>
> I wouldn't characterize any as 'showstoppers'....
>
> Thanks
>
> Paul
>
> --------------------------------------------------------------------------------------
>
> OpenID Provider Auth Policy Extension October
> 2008
>
>
> Abstract
>
> This extension to the OpenID Authentication protocol provides a
> mechanism by which a Relying Party can request that particular
> authentication policies be applied by the OpenID Provider when
> authenticating an End User. This extension also provides a
> mechanism
> by which an OpenID Provider may inform a Relying Party which
> authentication policies were used. Thus a Relying Party can
> request
> that the End User authenticate, for example, using a phishing-
> resistant or multi-factor authentication method.
>
> PM: suggest adding to the end 'and the OP can then respond with the
> actual method' ....
>
> This extension also provides a mechanism by which a Relying Party
> can
> request that the OpenID Provider communicate the levels of
> authentication used, as defined within one or more sets of
> requested
> custom Assurance Levels, and for the OpenID Provider to communicate
> the levels used.
>
> PM: 'Authentication' and 'assurance' are used interchangeably. Some
> text
> explaining the relationship between the two would be useful.
>
> This extension is not intended to provide all information regarding
> the quality of an OpenID Authentication assertion. Rather, it is
> designed to be balanced with information the Relying Party already
> has with regard to the OpenID Provider and the level of trust it
> places in it. If additional information is needed about processes
> such as new End User enrollment on the OpenID Provider, such
> information should either be transmitted out-of-band or in other
> extensions such as OpenID Attribute Exchange. Other aspects (e.g.
> security characteristics, credential provisioning, etc) could be
> dealt with in the future.
>
> PM: in fact, PAPE does indeed address other aspects like enrollment,
> albeit
> indirectly through the NIST levels or another framework. The
> relationship/differences between
> the PAPE authentication policies and the NIST assurance policies could
> be clarified.
>
> This extension is optional, though its use is certainly
> recommended.
> This extension can be used with OpenID Authentication versions 1.1
> and 2.0.
>
> PM: perhaps provide guidance on when the use of PAPE is appropriate?
>
> While none of the information transmitted using this extension
> can be
> verified by the Relying Party using technology alone, this does not
> limit the utility of this extension. Because there is no trust
> model
> specified by OpenID, Relying Parties must decide for themselves
> which
> Providers are trustworthy; likewise, RPs can decide whether to
> trust
> authentication policy claims from such OpenID Providers as well.
> As
> with other OpenID extensions, it is the Relying Party's
> responsibility to implement policy relative to the OpenID
> Provider's
> response.
>
> PM: the last seems an awkward reiteration of the previous sentences.
>
>
>
>
>
>
>
>
> Recordon, et al.
> [Page 2]
>
> OpenID Provider Auth Policy Extension October
> 2008
>
>
> Table of Contents
>
> 1.
> Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
> 1.1. Requirements
> Notation . . . . . . . . . . . . . . . . . . 4
> 1.2.
> Conventions . . . . . . . . . . . . . . . . . . . . . . . 4
> 1.3.
> Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
> 2. Extension
> Overview . . . . . . . . . . . . . . . . . . . . . . 6
> 3. Advertising Supported Authentication
> Policies . . . . . . . . 7
> 4. Defined Authentication
> Policies . . . . . . . . . . . . . . . 8
> 4.1. Custom Assurance Level Name
> Spaces . . . . . . . . . . . . 9
> 5. Authentication
> Protocol . . . . . . . . . . . . . . . . . . . 10
> 5.1. Request
> Parameters . . . . . . . . . . . . . . . . . . . . 10
> 5.2. Response
> Parameters . . . . . . . . . . . . . . . . . . . 11
> 6. Security
> Considerations . . . . . . . . . . . . . . . . . . . 14
> 6.1. NIST Assurance
> Levels . . . . . . . . . . . . . . . . . . 14
> Appendix A.
> Examples . . . . . . . . . . . . . . . . . . . . . . 16
> Appendix A.1. Authentication Method
> Classifications . . . . . . . 16
> Appendix B.
> Acknowledgements . . . . . . . . . . . . . . . . . . 20
> 7. Normative
> References . . . . . . . . . . . . . . . . . . . . . 21
> Authors'
> Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Recordon, et al.
> [Page 3]
>
> OpenID Provider Auth Policy Extension October
> 2008
>
>
> 1. Definitions
>
> 1.1. Requirements Notation
>
> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
> this
> document are to be interpreted as described in [RFC2119] .
>
> 1.2. Conventions
>
> Throughout this document, values are quoted to indicate that they
> are
> to be taken literally. When using these values in protocol
> messages,
> the quotes MUST NOT be used as part of the value.
>
> All OpenID 2.0 messages that contain a Provider Authentication
> Policy
> Extension (PAPE) element MUST contain the following extension
> namespace declaration, as specified in the Extensions section of
> [OpenIDAuthentication2.0] .
> openid.ns.<alias>=http://specs.openid.net/extensions/pape/1.0
>
> The actual extension namespace alias should be determined on a per-
> message basis by the party composing the messages, in such a manner
> as to avoid conflicts between multiple extensions. For the
> purposes
> of this document and when constructing OpenID 1.1 messages, the
> extension namespace alias SHALL be "pape".
>
> Additionally, this specification uses name spaces for the custom
> authentication level identification. It is in the form of
> openid.pape.auth_level.ns.<cust>=http://some.authlevel.uri
>
> The actual extension namespace alias should be determined on a per-
> message basis by the party composing the messages, in such a manner
> as to avoid conflicts between multiple extensions. For the
> purposes
> of this document and when constructing OpenID 1.1 messages, the one
> custom authentication level identification extension namespace
> defined by this specification is "nist". Others may also be
> defined
> and used by implementations, for example, "jisa".
>
> 1.3. Terminology
>
> The following terms are defined in [OpenIDAuthentication2.0] :
>
> o Identifier
>
> o OpenID Provider (OP)
>
> o Relying Party (RP)
>
>
>
>
> Recordon, et al.
> [Page 4]
>
> OpenID Provider Auth Policy Extension October
> 2008
>
>
> o User-Agent
>
> Authentication Method: An Authentication Method is a single
> mechanism by which the End User authenticated to their OpenID
> Provider, for example, a password or a hardware credential.
>
> Authentication Policy: An Authentication Policy is a plain-text
> description of requirements that dictate which Authentication
> Methods can be used by an End User when authenticating to their
> OpenID Provider. An Authentication Policy is defined by a URI
> which must be previously agreed upon by one or more OPs and RPs.
>
> PM: for above defn, suggest add that 'this spec defines 3
> authentication policies'
>
> PM: define 'assurance level' as well?
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Recordon, et al.
> [Page 5]
>
> OpenID Provider Auth Policy Extension October
> 2008
>
>
> 2. Extension Overview
>
> 1. As part of the [Yadis] Discovery process, OpenID Providers can
> optionally add supported authentication policies to an End
> User's
> XRDS document. This aids Relying Parties in choosing between
> multiple listed OPs depending on authentication policy
> requirements.
>
> PM: why constrain discovery to Yadis?
>
> 2. The Relying Party includes parameters in the OpenID
> Authentication request describing its preferences for
> authentication policy for the current assertion.
>
> PM: 'or assurance policy'
>
> 3. The OpenID Provider processes the PAPE request, prompting the
> End
> User to fulfill the requested policies during the
> authentication
> process.
>
> 4. As part of the OpenID Provider's response to the Relying Party,
> the OP includes PAPE information around the End User's
> authentication. An OP MAY include this response information
> even
> if not requested by the RP.
>
> PM: 'around' is awkward. Suggest 'describing'
>
> 5. When processing the OpenID Provider's response, the Relying
> Party
> takes the PAPE information into account when determining if the
> End User should be sent through additional verification steps
> or
> if the OpenID login process cannot proceed due to not meeting
> policy requirements.
>
> PM: suggest 'MAY take the PAPE information into account'
>
> PM: I question the use of 'verification', as it may be interpreted
> as meaning
> registration verification...
>
> PM: 'if the OpenID login process cannot proceed due to not meeting
> policy requirements' seems an awkward way to describe the RP
> choosing
> to not grant authz....
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Recordon, et al.
> [Page 6]
>
> OpenID Provider Auth Policy Extension October
> 2008
>
>
> 3. Advertising Supported Authentication Policies
>
> Via the use of [Yadis] within OpenID, Relying Parties are able to
> discover OpenID Provider service information in an automated
> fashion.
> This is used within OpenID Authentication for a RP to discover what
> version of the protocol each OP listed supports as well as any
> extensions, such as this one, that are supported. To aide in the
> process of a Relying Party selecting which OP they wish to interact
> with, it is STRONGLY RECOMMENDED that the following information be
> added to the End User's XRDS document. An OP may choose to
> advertise
> both custom levels and supported polices in the same <xrd:Service>.
> An OP should only advertise the authentication policies and custom
> assurance level namespaces that it supports.
>
> PM: 'following information' could be made more precise, i.e.
> 'supported PAPE policies'.
>
> PM: suggest tighten up to 'SHOULD/MUST only advertise the
> authentication policies'?
>
> When advertising supported policies, each policy URI MUST be
> added as
> the value of an <xrd:Type> element of an OpenID <xrd:Service>
> element
> in an XRDS document.
>
> Example:
> <xrd>
> <Service>
> <Type>http://specs.openid.net/auth/2.0/signon</Type>
> <Type>
> http://schemas.openid.net/pape/policies/2007/06/phishing-
> resistant
> </Type>
> <URI>https://example.com/server</URI>
> </Service>
> </xrd>
>
> When advertising supported custom Assurance Level name spaces, each
> name space URI MUST be added as the value of an <xrd:Type>
> element of
> an OpenID <xrd:Service> element in an XRDS document.
>
> Example:
> <xrd>
> <Service>
> <Type>http://specs.openid.net/auth/2.0/signon</Type>
> <Type>
> http://csrc.nist.gov/publications/nistpubs/800-63/SP800-63V1_0_2.pdf
> </Type>
> <URI>https://example.com/server</URI>
> </Service>
> </xrd>
>
>
>
>
>
>
>
>
> Recordon, et al.
> [Page 7]
>
> OpenID Provider Auth Policy Extension October
> 2008
>
>
> 4. Defined Authentication Policies
>
> The following are defined policies and policy identifiers
> describing
> how the End User may authenticate to an OP. Additional policies
> can
> be specified elsewhere and used without making changes to this
> document. The policies described below are designed to be a
> starting
> point to cover the most common use-cases. Additional polices can
> be
> found at http://schemas.openid.net/pape/policies/.
>
> When multiple policies are listed in the Relying Party's request,
> the
> OpenID Provider SHOULD satisfy as many of the requested policies as
> possible. This may require, for instance, that a user who has
> already been authenticated using one authentication method be re-
> authenticated with different or additional methods that satisfy the
> request made by the Relying Party. It is always the responsibility
> of the RP to determine whether the particular authentication
> performed by the OP satisfied its requirements; this determination
> may involve information contained in the PAPE response, specific
> knowledge that the RP has about the OP, and additional information
> that it may possess or obtain about the particular authentication
> performed.
>
> o Phishing-Resistant Authentication
>
>
> http://schemas.openid.net/pape/policies/2007/06/phishing-resistant
>
> An authentication mechanism where a party potentially under
> the
> control of the Relying Party can not gain sufficient
> information to be able to successfully authenticate to the
> End
> User's OpenID Provider as if that party were the End User.
> (Note that the potentially malicious Relying Party controls
> where the User-Agent is redirected to and thus may not send
> it
> to the End User's actual OpenID Provider).
>
> o Multi-Factor Authentication
>
>
> http://schemas.openid.net/pape/policies/2007/06/multi-factor
>
> An authentication mechanism where the End User
> authenticates to
> the OpenID Provider by providing more than one authentication
> factor. Common authentication factors are something you
> know,
> something you have, and something you are. An example
> would be
> authentication using a password and a software token or
> digital
> certificate.
>
> PM: the middle sentence feels more like belonging in a whitepaper ...
>
>
>
> Recordon, et al.
> [Page 8]
>
> OpenID Provider Auth Policy Extension October
> 2008
>
>
> o Physical Multi-Factor Authentication
>
>
> http://schemas.openid.net/pape/policies/2007/06/multi-factor-physical
>
> An authentication mechanism where the End User
> authenticates to
> the OpenID Provider by providing more than one authentication
> factor where at least one of the factors is a physical factor
> such as a hardware device or biometric. Common
> authentication
> factors are something you know, something you have, and
> something you are. This policy also implies the Multi-Factor
> Authentication policy
> (http://schemas.openid.net/pape/policies/2007/06/multi-
> factor)
> and both policies MAY BE specified in conjunction without
> conflict. An example would be authentication using a
> password
> and a hardware token.
>
> Of the policies defined above, two are not independent. All
> authentications satisfying the Multi-Factor Physical policy also
> satisfy the Multi-Factor policy. Therefore, whenever the OP
> returns
> a result saying that Multi-Factor Physical authentication was
> performed it MUST also indicate that Multi-Factor authentication
> was
> performed.
>
> PM: While I understand the motivation for this, I suggest it
> introduces a
> dangerous precedent for dealing with dependencies between
> authentication policies.
>
>
> 4.1. Custom Assurance Level Name Spaces
>
> Custom Assurance Levels are optional. The namespaces may be
> defined
> by various parties, such as country or industry specific standards
> bodies, or other groups or individuals.
>
> The namespace URI should be chosen with care to be unambiguous when
> used as a <xrd:Type> element to advertise the namespaces
> supported by
> the OP.
>
> The custom Assurance Level namespace should define the meaning of
> the
> strings that are returned by the OP in the
> openid.pape.auth_level.<cust> element.
>
> PM: why is 'should' not a 'MUST'? How could it be anything else?
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Recordon, et al.
> [Page 9]
>
> OpenID Provider Auth Policy Extension October
> 2008
>
>
> 5. Authentication Protocol
>
> 5.1. Request Parameters
>
> The following parameters MUST be included during an OpenID
> Authentication request [OpenIDAuthentication2.0] by the Relying
> Party
> that uses this extension unless marked as optional.
>
> o openid.ns.pape
>
> Value:
> http://specs.openid.net/extensions/pape/1.0
>
> o openid.pape.max_auth_age
>
> (Optional) If the End User has not actively authenticated to
> the OP within the number of seconds specified in a manner
> fitting the requested policies, the OP SHOULD authenticate
> the
> End User for this request using the requested policies.
> The OP
> MUST actively authenticate the user and not rely on a browser
> cookie from a previous authentication.
>
> PM: how can the SHOULD and MUST of the last two sentences be
> reconciled? By
> the OP freshly authenticating the user, but perhaps not with the
> requested
> policy mech?
>
> Value: Integer value greater than or equal to zero in
> seconds.
>
> If an OP does not satisfy a request for timely
> authentication,
> the RP may decide not to grant the End User access to the
> services provided by the RP. If this parameter is absent
> from
> the request, the OP should authenticate the user at its own
> discretion.
>
> PM: the first sentence seems redundant, given the oft-stated ability
> of the
> RP to do what it chooses
>
> o openid.pape.preferred_auth_policies
>
> PM: why is not 'preferred' used consistently on all of the request
> params?
>
> Zero or more authentication policy URIs representing
> authentication policies that the OP SHOULD satisfy when
> authenticating the user. If multiple policies are requested,
> the OP SHOULD satisfy as many of them as it can.
>
> Value: Space separated list of authentication policy URIs.
>
> If no policies are requested, the RP may be interested in
> other
> information such as the authentication age.
>
>
>
>
>
>
>
>
>
>
> Recordon, et al. [Page
> 10]
>
> OpenID Provider Auth Policy Extension October
> 2008
>
>
> Example:
> openid.pape.preferred_auth_policies=
> http://schemas.openid.net/pape/policies/2007/06/phishing-
> resistant
> http://schemas.openid.net/pape/policies/2007/06/multi-factor
>
> o openid.pape.auth_level.ns.<cust>
>
> PM: should this param not be named something like
> 'openid.pape.assur_level.ns.<cust>'
> in order to distinguish the assurance levels from the prior
> authentication URIs?
>
>
> (Optional) The name space for the custom Assurance Level.
> Assurance levels and their name spaces are defined by various
> parties, such as country or industry specific standards
> bodies,
> or other groups or individuals.
>
> Value: URL that represents this Assurance Level.
>
>
> Example:
> openid.pape.auth_level.ns.nist=
> http://csrc.nist.gov/publications/nistpubs/800-63/SP800-63V1_0_2.pdf
> openid.pape.auth_level.ns.jisa=
> http://www.jisa.or.jp/spec/auth_level.html
>
> o openid.pape.preferred_auth_level_types
>
> PM: likewise, suggest a name that acknowledges these are 'assurance
> levels'
> more so than 'authentication level' ...
>
> (Optional) A list of the name space aliases for the custom
> Assurance Level name spaces that the RP requests be present
> in
> the response, in the order of its preference.
>
>
> PM: Should not this param be mandatory in the request if the
> corresponding
> openid.pape.auth_level.ns.<cust> param is present? If omitted, how
> should
> the OP rank the assurance level frameworks?
>
>
> Value: Space separated list of the name space aliases, in the
> order of the RP's preference.
>
> Example:
> openid.pape.preferred_auth_levels=jisa nist
>
> PM: the assymmetry between assurance level frameworks and
> authentication
> policies (i.e that an RP can indicate its preferences for the
> latter and
> not the former) is strange and warrants explanation/justification
>
>
> 5.2. Response Parameters
>
> In response to a Relying Party's request, the following parameters
> MUST be included in the OpenID Authentication Response. All
> response
> parameters MUST be included in the signature of the Authentication
> Response. It is RECOMMENDED that an OP supporting this extension
> include the following parameters even if not requested by the
> Relying
> Party.
>
> PM: the above seems to unduly emphasize the RP first scenario and
> neglect the
> possibility of OP inititated?
>
> All response parameters MUST describe the End User's current
> session
> with the OpenID Provider.
>
>
> Recordon, et al. [Page
> 11]
>
> OpenID Provider Auth Policy Extension October
> 2008
>
>
> o openid.ns.pape
>
> Value:
> http://specs.openid.net/extensions/pape/1.0
>
> o openid.pape.auth_policies
>
> One or more authentication policy URIs representing policies
> that the OP satisfied when authenticating the End User.
>
> Value: Space separated list of authentication policy URIs.
>
> Note: If no policies were met though the OP wishes to convey
> other information in the response, this parameter MUST be
> included with the value of
> http://schemas.openid.net/pape/policies/2007/06/none.
>
>
> Example:
> openid.pape.auth_policies=
> http://schemas.openid.net/pape/policies/2007/06/multi-factor
> http://schemas.openid.net/pape/policies/2007/06/multi-factor-physical
>
> o openid.pape.auth_time
>
> (Optional) The most recent timestamp when the End User has
> actively authenticated to the OP in a manner fitting the
> asserted policies.
>
> Value: The timestamp MUST be formatted as specified in
> section
> 5.6 of [RFC3339] , with the following restrictions:
>
> + All times must be in the UTC time zone, indicated with a
> "Z".
>
> + No fractional seconds are allowed
>
>
>
> Example:
> 2005-05-15T17:11:51Z
>
> Note: If the RP's request included the
> "openid.pape.max_auth_age" parameter then the OP MUST include
> "openid.pape.auth_time" in its response. If
> "openid.pape.max_auth_age" was not requested, the OP MAY
> choose
> to include "openid.pape.auth_time" in its response.
>
>
>
> Recordon, et al. [Page
> 12]
>
> OpenID Provider Auth Policy Extension October
> 2008
>
>
> o openid.pape.auth_level.ns.<cust>
>
> (Optional) The name space for the custom Assurance Level
> defined by various parties, such as a country or industry
> specific standards body, or other groups or individuals.
>
> Value: URL that represents this Assurance Level.
>
>
>
> Example:
> openid.pape.auth_level.ns.nist=
> http://csrc.nist.gov/publications/nistpubs/800-63/SP800-63V1_0_2.pdf
> openid.pape.auth_level.ns.jisa=
> http://www.jisa.or.jp/spec/auth_level.html
>
> o openid.pape.auth_level.<cust>
>
> (Optional) The Assurance Level as defined by the above
> standards body, group, or individual that corresponds to the
> authentication method and policies employed by the OP when
> authenticating the End User. A custom Assurance Level
> definition MAY define additional subparameter values that are
> expressed within its namespace, although for reasons of
> simplicity, this SHOULD be avoided if possible.
>
> PM: The example below suggests that the OP MAY include multiple of
> these,
> one for each assurance framework. Suggest adding text in the above
> to make this explicit.
>
> PM: Is the OP precluded from adding multiple of these params for a
> single
> assurance level framework, i.e. to say nist=1 and nist=2 on the same
> response?
>
> Value: Strings defined according to this Assurance Level.
>
>
>
> Example:
> openid.pape.auth_level.nist=1
> openid.pape.auth_level.jisa=2
>
>
>
>
>
>
>
>
> Recordon, et al. [Page
> 13]
>
> OpenID Provider Auth Policy Extension October
> 2008
>
>
> 6. Security Considerations
>
> Per commonly accepted security practices, it should be noted that
> the
> overall strength of any authentication is only as strong as its
> weakest step. It is thus recommended that provisioning of
> phishing-
> resistant and other credentials stronger than shared secrets should
> be accomplished using methods that are at least as strong as the
> credential being provisioned. By counter-example, allowing
> people to
> retrieve a phishing-resistant credential using only a phishable
> shared secret negates much of the value provided by the phishing-
> resistant credential itself. Similarly, sometimes using a
> phishing-
> resistant method when a phishable method continues to also
> sometimes
> be employed may still enable phishing attacks to compromise the
> OpenID.
>
> PM: the last sentence is awkward. Perhaps an example would clarify?
>
> OPs SHOULD attempt to satisfy the authentication policies requested
> by the RP and the reply SHOULD minimally contain at least the
> subset
> of the requested policies that the authentication performed
> satisfied. The OP MAY also choose to return additional policies
> that
> the authentication performed satisfied, even if not requested.
>
> PM: how is the above a security consideration? It feels out of place
>
> If the RP requested that an authentication level or levels be
> returned and the OP supports some or all of those level types, then
> the OP SHOULD return the actual level value for each of the
> supported
> types requested, if available.
>
> PM: similarly, this is not a security issue, but would seem a better
> fit as a
> normative rule for the openid.pape.auth_level.<cust> param of the
> response message
>
>
> 6.1. NIST Assurance Levels
>
> PM: why is this section a sub-section of Security Considerations?
>
> PM: Suggest adding some text to justify hiliting NIST above other
> assurance frameworks.
>
> National Institute of Standards and Technology (NIST) in Special
> Publication 800-63 [NIST_SP800-63] defines a set of Assurance
> Levels
> from 1 to 4. These may be returned by the OP to the RP to
> communicate which NIST level the identity proofing, authentication
> method, and policies employed by the OP when authenticating the End
> User corresponds to.
>
> Value: Integer value between 0 and 4 inclusive.
>
> PM: It seems misleading to arbitrarily append a level 0 onto the
> NIST range.
> Any why only for NIST? Why not JISA etc?
>
> Note: Level 0 is not an assurance level defined by NIST, but rather
> SHOULD be used to signify that the OP recognizes the parameter and
> the End User authentication did not meet the requirements of
> Level 1.
> See Appendix A.1.2 for high-level example classifications of
> authentication methods within the defined levels. Authentication
> using a long-lived browser cookie, for instance, is one example
> where
> the use of "level 0" is appropriate. Authentications with level 0
> should never be used to authorize access to any resource of any
> monetary value whatsoever. The previous sentence should not be
> construed as implying that any of the other levels are
> recommended or
> appropriate for accessing resources with monetary value either
>
> PM: how is 'never be used to authorize access to any resource of any
> monetary value whatsoever' consistent with the frequent statements
> elsewhere that it is the RP's choice, non-normative text or otherwise?
>
>
> Recordon, et al. [Page
> 14]
>
> OpenID Provider Auth Policy Extension October
> 2008
>
>
> without the Relying Party doing an appropriate risk assessment of
> the
> particular OpenID provider asserting them and their issuance and
> authentication procedures as they apply to the particular online
> interaction in question.
>
> PM: must the RP do the assessment, or could not some trusted 3rd
> party assessor ...?
>
> Depending on the particular use case being satisfied by the
> authentication response and PAPE information, the OpenID Provider
> will have to make a decision, ideally with the consent of the End
> User, as if it will include the "openid.pape.auth_level.nist"
> parameter. This information is designed to give Relying Parties
> more
> information around the strength of credentials used without
> actually
> disclosing the specific credential type. Disclosing the specific
> credential type can be considered a potential privacy or security
> risk.
>
> PM: The above warning gives the impression that for an OP to include a
> NIST level presents a greater privacy risk (and so it would be more
> appropriate to ask the user for consent) than would be the case for
> the
> PAPE defined authn policies? But NIST levels do not disclose specific
> credential types any more than the specific PAPE defined authn
> policies
>
> PM: Could not the above be generalized into a 'Privacy
> Consideration' section,
> or pulled into Security Considerations?
>
> It is RECOMMENDED that this parameter always be included in the
> response from the OP. This holds true even in cases where the End
> User authentication does not meet one of the defined Authentication
> Policies. For example, if the End User is authenticating using a
> password via HTTPS there is still value to the RP in knowing if the
> strength of the Password corresponds to the entropy requirements
> laid
> out by Level 1 or 2 or that it does not even meet the minimum
> requirement for the lowest level. With that said, discretion needs
> to be used by OP's as conveying that one of their End User's has a
> weak password to an "un-trustworthy" RP would not generally be
> considered a good idea.
> --
> <image001.gif>
> _______________________________________________
> specs-pape mailing list
> specs-pape at openid.net
> http://openid.net/mailman/listinfo/specs-pape
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-board/attachments/20081222/cfbc6ccf/attachment-0002.htm>
More information about the board
mailing list