[specs-pape] Draft 6 published and multiple implementations ready for you to test with

[Ben Laurie]

On Mon, Oct 20, 2008 at 6:24 PM, John Bradley <john.bradley at wingaa.com> wrote:
> We do also have the Yahoo use case of using nist=0 to indicate a long lived
> cookie was used and not to trust the authentication for monetary uses etc.
> If levels get push-back from implementers that will be much less useful to
> them.
> Perhaps we also need a policy in 4:
> http://schemas.openid.net/pape/policies/2007/06/long-lived-token
> Authentication using a long-lived browser cookie. Authentications with this
> policy should never be used to authorize access to any resource of any
> monetary value whatsoever.

If you start down this path, you could end up with a very long list of
specific policies.

> The problem in specifying MUSTs in the basic policies is that they are
> intended to fit the general case.  Without some trust framework between the
> OP and RP the RP cant Trust any of it.
> The trust frameworks as they are defined can add more specific Policies
> where the Musts are defined along with auditing etc.
> =jbradley
> On 20-Oct-08, at 9:50 AM, Andrew Arnott wrote:
>
> Just my personal opinion:
> While the extensible auth_level addition does make PAPE more powerful, as
> you say it adds complexity.
> A much easier enhancement to PAPE that would add more value (in my opinion)
> would be to define much more strictly what it means to be phishing
> resistant, and all the other default policies.  There was an email a week or
> two back that I think you may have seen that countered that without defining
> these, an RP cannot rely on an OP satisfying them even if it claims to,
> since "phishing resistance" could be defined anywhere from "we use an SSL
> cert" to "we don't use passwords but certificates instead".
>
> I'd really like to see a bunch of MUSTs added to the spec regarding what an
> OP must do to qualify itself to send out assertions that it is phishing
> resistant, etc.
>
> From: John Bradley [mailto:john.bradley at wingaa.com]
> Sent: Monday, October 20, 2008 9:27 AM
> To: Andrew Arnott
> Cc: Ben Laurie; Mike Jones; specs-pape at openid.net; larry drebes; Brian
> Kissel
> Subject: Re: [specs-pape] Draft 6 published and multiple implementations
> ready for you to test with
>
> You are the first person to bring it up.
>
> The Auth levels are a later addition to the Spec.  I think David R. was the
> one who suggested them.
>
> So far the only examples I have seen for values are numbers to represent the
> NIST levels though the element is type string.
>
> PAPE started out as a simple way for an RP to request better than default
> auth,  and have a OP add a indication to the assertion about how the user
> was authenticated.
>
> It seems to be growing into much more complicated policy
> communication mechanism.
>
> I am not opposed to that as long as it retains its utility for the original
> intended use.
>
> Do we need to say at this point there will be two types of PAPE libs and
> interfaces one with Levels and one without(PAPE Simple).
>
> David Recordon is always pushing for simpler to implement.  I have concerns
> that this scope creep may make PAPE something that won't get included.
>
> Mike I know you may kill me for raising this.
>
> Differentiating between the two conformance levels may be useful.
>
> =jbradley
>
>
> On 20-Oct-08, at 9:07 AM, Andrew Arnott wrote:
>
> Yes, John, that was exactly the issue I was running into in building the
> API: dictionary of key/values within a namespace or just 'value'.
>
> Mandating a format the sub-namespace can use would make the target of an API
> much easier to envision and have stable.  Mandating a single value would
> cause more complex auth_level that need multiple values to come up with
> creating ways of encoding their values as a single string – the API would
> then be accurate but would not be very helpful, as the client of that API
> would need to build into itself the knowledge of how to decode the string.
> A dictionary would make the common, simpler case more complex though.
>
> Do we have any examples at all (or even ideas) of how multiple values might
> be used for an auth_level?
>
> From: John Bradley [mailto:john.bradley at wingaa.com]
> Sent: Monday, October 20, 2008 8:55 AM
> To: Andrew Arnott
> Cc: Ben Laurie; Mike Jones; specs-pape at openid.net; larry drebes; Brian
> Kissel
> Subject: Re: [specs-pape] Draft 6 published and multiple implementations
> ready for you to test with
>
> In the openID specs we haven't talked much about the API to upper level apps
> that are using these libs.
>
> I see how the API will likely need to be different depending on if
> the response from a level namespace is a string or an array of what are name
> value pairs.
>
> Should an OP be allowed to only return a single string for the namespace to
> simplify the API?
> We don't mandate that now.
>
> Or should we make it clear to RP authors that some level namespaces may have
> multiple parameters and they should accommodate that in there API.  We don't
> want a situation down the road where a namespace only works in some RPs
> because of the internal API.
>
> We should probably do one or the other.
>
> The API for integrating PAPE with upper-level policy apps is going to be
> interesting as it is.
>
> Thoughts?
>
> =jbradley
> On 20-Oct-08, at 8:22 AM, Andrew Arnott wrote:
>
>
> John,
>
> Your wording clarification sounds good. I don't think you need to
> provide samples for how a namespace might be customized either. But
> the wording you added about how the namespace could be further
> customized was very helpful.
>
> While implementing the spec myself, I saw the vagueness and as the
> possibility of customizing the namespace complicated the general
> library I was writing I crossed my fingers and gambled that it wasn't
> allowed. Adding the sentence you proposed would have prevented me from
> doing that and my library would have been more correct.
>
> --
> Andrew
>
> If this message seems short, there are two big thumbs and one little
> iPhone behind it.
>
> On Oct 19, 2008, at 7:34 PM, "John Bradley" <john.bradley at wingaa.com>
> wrote:
>
>
>
> Hi Andrew,
>
>
>
> For 5.1 we should change to:
>
>
>
> ----------------------------------
>
> openid.pape.preferred_auth_level_types
>
> (Optional) The list of Custom Assurance Level name spaces that the RP
>
> would like in the response in order of preference.
>
>
>
> Value: The space separated list of the name space aliases of the
>
> custom Assurance Level that RP requests, in the order of its
>
> preference.
>
>
>
> -----------------------------
>
>
>
> Mike this is a wording clarification not a change in functionality
>
>
>
> For the other part of your question.
>
>
>
> Once someone defines a namespace under openid.pape.auth_level it is
>
> theirs to do with as they like.  People who use those custom assurance
>
> levels will need to document how to use them.
>
>
>
> Are you suggesting that we add something in 5.1 like:
>
>
>
> openid.pape.auth_level.ns.<cust>
>
> (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. Custom Assurance level namespaces may be parameterized if
>
> documented by the namespace.
>
>
>
> Value: URL that represents this Assurance Level.
>
>
>
> And perhaps 5.2 to include an example in the response?
>
>
>
> I don't know if we want to dig in to all the ways someone can use
>
> namespaces.
>
> I don't want to preclude it in the spec ether.
>
>
>
> Personally I would leave this as it is.  Digging into all the things
>
> someone might do with custom assurance levels is beyond the scope of
>
> the base spec and can be documented in the namespace doc itself.
>
>
>
> If other people want some more detail around this I can work something
>
> up.
>
>
>
> Thanks for the feedback.
>
> Regards
>
> John  B.
>
> =jbradley
>
>
>
> On 19-Oct-08, at 6:46 PM, Andrew Arnott wrote:
>
>
>
> Here were some of my thoughts implementing the latest draft in
>
> DotNetOpenId:
>
>
>
> 1.      Section 5.2, description for openid.pape.auth_level.<cust>
>
> does not clearly state (to me) whether multiple parameters that
>
> include the alias can be defined.  They give the example of
>
> openid.pape.auth_level.nist=1, but I don't see anything in the spec
>
> specifically allowing or forbidding
>
> openid.pape.auth_level.nist.var2=somevalue2.  I wonder if the spec
>
> can be enhanced to state whether a single auth level type is allowed
>
> to have sub-variables of this type.
>
> 2.      Section 5.1, under openid.pape.preferred_auth_level_types
>
> the first and second paragraphs are almost identical.  I wonder if
>
> one should be removed, or one reworded to be more useful.
>
>
>
> -----Original Message-----
>
> From: John Bradley [mailto:john.bradley at wingaa.com]
>
> Sent: Sunday, October 19, 2008 9:22 AM
>
> To: Ben Laurie
>
> Cc: Mike Jones; Andrew Arnott; specs-pape at openid.net; larry drebes;
>
> Brian Kissel
>
> Subject: Re: [specs-pape] Draft 6 published and multiple
>
> implementations ready for you to test with
>
>
>
> True enough.
>
>
>
> I think we have made improvements.
>
>
>
> However from the point of view of the editors who unlike me are
>
> overly
>
> polite,  I would hope that everyone takes a good read of the whole
>
> spec at this point and gets there changes and comments in.
>
>
>
> I understand that changes themselves need to be reviewed.
>
>
>
> We don't want this to take another year to get to public review on
>
> this.   So please everyone I know this is a pain but lets try and get
>
> all the comments on the current draft in so we can move forward with
>
> this.
>
>
>
> There are people waiting to attack us for this work in the larger
>
> community lets not keep them from there sport unduly.
>
>
>
> Regards
>
> John Bradley
>
> =jbradley
>
>
>
>
>
>
>
> On 19-Oct-08, at 6:58 AM, Ben Laurie wrote:
>
>
>
> On Sat, Oct 18, 2008 at 5:48 PM, John Bradley
>
> <john.bradley at wingaa.com> wrote:
>
> I am OK with SHOULD to MUST it is clearer.
>
> I hope this is the last of the changes Ben?
>
>
>
> So do I, but it's done when it's done.
>
>
>
> Thanks Mike.
>
> John B.
>
> On 18-Oct-08, at 9:40 AM, Mike Jones wrote:
>
>
>
> I caught the missing "Physical" as well when proofreading for draft
>
> 7.  It's
>
> already fixed there.
>
>
>
> I could agree to change the SHOULD to a MUST because it would
>
> simplify life
>
> for relying parties.  I'll make this one-word revision to draft 7
>
> shortly
>
> unless I hear objections.
>
>
>
>                            -- Mike
>
>
>
> -----Original Message-----
>
> From: Ben Laurie [mailto:benl at google.com]
>
> Sent: Saturday, October 18, 2008 5:34 AM
>
> To: Mike Jones
>
> Cc: specs-pape at openid.net; Andrew Arnott; larry drebes; Brian
>
> Kissel
>
> Subject: Re: [specs-pape] Draft 6 published and multiple
>
> implementations
>
> ready for you to test with
>
>
>
> On Fri, Oct 17, 2008 at 4:14 AM, Mike Jones <Michael.Jones at microsoft.com
>
>
>
> wrote:
>
>
>
> Having thought about Ben's feedback, I have to agree with him about
>
> the lack
>
> of clarity of much of the language cited in his note.  The "smart
>
> decisions"
>
> language *is* incredibly vague and is not actionable by either OPs
>
> or RPs.
>
> Unless someone proposes specific language on this topic that is
>
> clear and
>
> actionable by OPs and RPs, I'm going to delete the paragraph
>
> referenced from
>
> the Security Considerations section, as the spec will actually be
>
> clearer
>
> without it.
>
>
>
> I also propose to reword the somewhat muddy "when multiple policies
>
> are
>
> listed..." paragraph in Section 4 for clarity as follows:
>
>
>
> "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."
>
>
>
> Then, after the policies are defined, I would propose to insert the
>
> following paragraph, which covers the topic
>
> ...
>
> [Message clipped]