[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