[specs-pape] Draft 6 published and multiple implementations ready for you to test with
Mike Jones
Michael.Jones at microsoft.com
Mon Oct 20 10:57:21 PDT 2008
I hate to say it, but this is an example of an authentication method - not an authentication policy. As such, it's out of scope.
Besides, in practice, asking for *no* policies with PAPE will likely result in sites that do perform authentication using long-lived cookies doing so, and they can report this in practice using NIST "level 0". Therefore, I believe that no change is warranted in the spec, as OPs already have a way of warning RPs that this is what they did.
-- Mike
From: David Recordon [mailto:drecordon at sixapart.com]
Sent: Monday, October 20, 2008 10:50 AM
To: John Bradley; Allen Tom
Cc: Andrew Arnott; Brian Kissel; Mike Jones; Larry Drebes; specs-pape at openid.net
Subject: Re: [specs-pape] Draft 6 published and multiple implementations ready for you to test with
+1 to a policy like that. Allen, thoughts?
On Oct 20, 2008, at 7:24 PM, John Bradley 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.
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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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 of the relationships
between the
defined policies:
"Of the policies defined above, two are not independent. All
authentications satisfying the Multi-Factor policy also satisfy the
Multi-Factor policy. Therefore, whenever the OP returns a result
saying
that Multi-Factor Physical authentication was performed it SHOULD
also
indicate that Multi-Factor authentication was performed."
You're missing a "Physical" in here. Also, why "SHOULD", why not
"MUST"?
Thanks Ben, for pushing us towards greater clarity in the
specification.
-- Mike
-----Original Message-----
From: Ben Laurie [mailto:benl at google.com]
Sent: Thursday, October 16, 2008 3:34 AM
To: Mike Jones
Cc: specs-pape at openid.net<mailto: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
I am happier about the language around phishing-resistant
credentials,
but I find this annoyingly vague:
"OpenID Providers need to make smart decisions as to how to
describe
the authentication performed with respect to that requested by the
Relying Party. For example, if the RP were to request
phishing-resistant authentication it may or may not make sense for
the
OP to actually tell it that the End User did in fact perform
phishing-resistant, physical multi-factor authentication."
If you insist on including this (IMO misguided) "advice" then you
should at least give some guidance as to _when_ it might make sense
and when it might not (since the arguments I've heard about this
are
to do with RPs not OPs, I suspect the answers are going to involve
telepathy).
" Likewise, an OP MAY choose to respond with a level or levels used
for the particular authentication even in some cases where this
information was explicitly requested."
I can't scan this. Is there a "not" missing?
Also, this is counterproductive:
"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. This might mean that the OP needs to understand the
relationship
between policies (such as if one encompasses another or if one is
stronger than another). This also means that when the RP processes
the
OP's response, it will have to make its own determinations as to if
its requirements were met. For instance, if the RP requested
Multi-Factor Authentication and the OP authentication employed
Multi-Factor Physical Authentication, it is recommended that the OP
include both policies in the response."
Since MFA is clearly true if MFPA is true, then you should either
mandate that is MUST be included, or that it MUST NOT. Saying that
it
is "recommended" means the RP has to assume the OP didn't follow
the
recommendation, so nothing is gained.
Also, if you want OPs to consistently understand the relationship
between policies, then you'd better spell that out, or they won't.
On Thu, Oct 16, 2008 at 10:00 AM, Mike Jones
<Michael.Jones at microsoft.com<mailto:Michael.Jones at microsoft.com>> wrote:
PAPE draft 6 is now available at
http://openid.net/specs/openid-provider-authentication-policy-extension-1_0-06.html
and
http://openid.net/specs/openid-provider-authentication-policy-extension-1_0-06.txt
.
Changes were John's clarifications discussed on the list, adding
the second
paragraph of the abstract (clarifying up front that authentication
policies
and levels are distinct and both supported), making it clear that
not just
standards orgs could define levels, grammatical cleanups that
resulting from
me running a grammar checker, and XML cleanups so that a .txt
version could
be successfully generated and so the examples were consistently
formatted.
There should have been no semantic changes between draft 5 and
draft 6.
Thanks to all of you who suggested ways to further clarify the
intent of the
text.
Even more exciting, there are now four implementations of this spec
for you
to test - one from the DotNetOpenId project and three from
JanRain. Please
kick the tires at:
- http://nerdbank.org/pape.demo/
- http://openidenabled.com/php-openid/trunk/examples/consumer/ and
http://openidenabled.com/php-openid/trunk/examples/server/
server.php
- http://openidenabled.com/python-openid/trunk/examples/consumer/
and
http://openidenabled.com/python-openid/trunk/examples/server/
- http://openidenabled.com/ruby-openid/trunk/examples/consumer/ and
http://openidenabled.com/ruby-openid/trunk/examples/
You should also be able to test the relying parties against
myopenid.com and
signon.com, since we didn't change the authentication policies
syntax.
Unless your testing using these implementations reveals problems
with the
spec, I believe we're now ready for the member vote to approve the
spec. If
I don't hear of problems that the implementations revealed in the
specification by early next week, I'll plan on announcing the vote.
Thanks all for getting us to this point!
-- Mike
_______________________________________________
specs-pape mailing list
specs-pape at openid.net<mailto:specs-pape at openid.net>
http://openid.net/mailman/listinfo/specs-pape
_______________________________________________
specs-pape mailing list
specs-pape at openid.net<mailto:specs-pape at openid.net>
http://openid.net/mailman/listinfo/specs-pape
_______________________________________________
specs-pape mailing list
specs-pape at openid.net<mailto:specs-pape at openid.net>
http://openid.net/mailman/listinfo/specs-pape
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openid.net/pipermail/specs-pape/attachments/20081020/0650c5ab/attachment-0001.htm
More information about the specs-pape
mailing list