Re: OpenID Provider Authentication Policy Extension

2007-08-24 Thread Johnny Bufu
David,

On 9-Aug-07, at 11:28 AM, Johnny Bufu wrote:
 On 21-Jul-07, at 4:55 PM, Recordon, David wrote:
 5.2

 2) I'm fine with time coming back instead of number of seconds.

 I wanted to bring openid4java up to the latest PAPE spec, and it
 seems the above was not checked in yet. Do you still have it on your
 todo list, or would it help if I sent you a proposed patch for it?

Did you have a chance to have a look at this? Not sure if you're  
having second thoughts about it, or just slipped through your busy  
schedule.

Would be great if this change went in the PAPE spec sometime soon, so  
that it can be included in the next release of openid4java.


Thanks,
Johnny

___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs


Re: OpenID Provider Authentication Policy Extension

2007-07-23 Thread Johnny Bufu

On 21-Jul-07, at 4:55 PM, Recordon, David wrote:
 5.1
 1) Clarified.

 2  3) Changed the MUST to a SHOULD, since the intent was never to
 restrict what a user could do.

 4) Changed to Integer

 2) I'm fine with time coming back instead of number of seconds.

 3) Changed to integer.

Great, thanks. Were these checked-in? I don't see them in SVN yet.

 5.2
 1) What is the use-case for this?  As the parameter always  
 describes the
 policies returned in pape_auth_policies, the Provider should always  
 know
 how long ago the user authenticated within the session.

Depending on how 'active authentication' is defined, there may be no  
such authentication performed at all. If there is no 'active  
authentication', there can't be an age for it either.

Specifically, Sxipper never prompts users for their password (that's  
what I think 'active' means). Maybe also clarify then 'active  
authentication'?

Or, if auth_age/time is intended to describe only the requested /  
performed authentication policies, remove the 'active' word from the  
description of the field, and define a new 'active authentication'  
policy (which can be requested separately), and tie the auth_age/time  
in the response to it.


Thanks,
Johnny

___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs


RE: OpenID Provider Authentication Policy Extension

2007-07-21 Thread Recordon, David
Thanks, definitely am!  Just catching up on a lot of email now.

--David

-Original Message-
From: Johnny Bufu [mailto:[EMAIL PROTECTED] 
Sent: Friday, July 13, 2007 11:05 AM
To: Recordon, David
Cc: specs@openid.net
Subject: Re: OpenID Provider Authentication Policy Extension

David,

On 22-Jun-07, at 9:46 AM, Recordon, David wrote:

 So please, check it out and let me know what you think...especially
 around the questions in the Editorial Comments section at the end.

 http://openid.net/specs/openid-provider-authentication-policy- 
 extension-
 1_0-01.html

Hope you're still welcoming feedback on this..

While trying to explain what PAPE is/does, I noticed that the term  
'authentication policy' is not explicitly defined in the spec (and  
how a policy differentiates from a specific authentication  
mechanism). A clear definition could help eliminate confusion between  
the two.


Johnny

___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs


RE: OpenID Provider Authentication Policy Extension

2007-07-21 Thread Recordon, David
1) I imagine the URLs will become live at some point. :)

2) I wouldn't mind renaming it to no-shared-secrets which can also
have a corresponding less secure policy of shared-secret-second or
something like that which means the user provided a shared secret only
after first providing something like a client side certificate.  Also,
the URLs are versioned (by date) which allows their definitions to
evolve.

3) Like the http://schemas.openid.net/pape/policies/2007/06/none
approach, it was required so a RP could tell the difference between a
Provider not supporting the extension in the response versus not using
any policies.

4) Yeah.

Thanks,
--David

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hans
Granqvist
Sent: Friday, June 22, 2007 3:50 PM
To: Recordon, David
Cc: specs@openid.net
Subject: Re: OpenID Provider Authentication Policy Extension

A few comments:

* Would be great if all the namespace URLs resolved into live links.
It always helps in the XML world and probably would in here too.

* Section 4 Defined Authentication Policies

We've talked about this before, but I just want to restate that it is
a bad idea to name a policy based on its inferred values.
Phishing-resistant implies a quality that is not necessarily
measurable. Quality can also shift over time.

The other policies are measurable (you can count number of  factors
used, for example).

I'd strongly advise renaming phishing-resistant to something like
no-secrets-shared (you can probably come up with a more succinct
term)

* 5.2 response params

Requiring openid.pape.auth_policies to have a null value if no
policies were met seems odd (and it may break processing where a value
is always expected by the parser). Better would be to explicitly state
that no policies were met by a predefined literal or URL. For example
openid.pape.auth_policies=http://schemas.openid.net/pape/policies/2007/0
6/none

* Section 7 Examples

I wanted to see some examples on how PAPE is used in the messages.
Maybe add a few?


I like the work. However, the spec is optional. I was hoping
finalizing auth 2.0 would be top priority.

-Hans

On 6/22/07, Recordon, David [EMAIL PROTECTED] wrote:
 Over the past few weeks I've been working on the OpenID Provider
 Authentication Policy Extension which is designed to replace the work
I
 did last year with the Assertion Quality Extension.

 Generally, the goal of this extension is to provide Relying Parties
with
 more information about how the End User authenticated to their
Provider.
 This is done by a mix of the RP requesting certain policies (such as
 phishing-resistant or multi-factor), the OP helping the End User
through
 the authentication process, and then in the OpenID Authentication
 response including the policies that were met as well as optionally a
 strength level for the overall authentication.

 This extension doesn't speak at all toward trust of the End User or
 Provider, so RPs will still have to decide if they believe the
 information returned about the authentication in the response.

 So please, check it out and let me know what you think...especially
 around the questions in the Editorial Comments section at the end.


http://openid.net/specs/openid-provider-authentication-policy-extension-
 1_0-01.html

http://openid.net/specs/openid-provider-authentication-policy-extension-
 1_0-01.txt

 Thanks,
 --David
 ___
 specs mailing list
 specs@openid.net
 http://openid.net/mailman/listinfo/specs

___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs


RE: OpenID Provider Authentication Policy Extension

2007-07-21 Thread Recordon, David
5.1 
1) Clarified.

2  3) Changed the MUST to a SHOULD, since the intent was never to
restrict what a user could do.

4) Changed to Integer

5.2
1) What is the use-case for this?  As the parameter always describes the
policies returned in pape_auth_policies, the Provider should always know
how long ago the user authenticated within the session.

2) I'm fine with time coming back instead of number of seconds.

3) Changed to integer.

Thanks,
--David


 -Original Message-
From: Johnny Bufu [mailto:[EMAIL PROTECTED] 
Sent: Thursday, June 28, 2007 7:31 PM
To: Recordon, David
Cc: specs@openid.net
Subject: Re: OpenID Provider Authentication Policy Extension

David,

On 22-Jun-07, at 9:46 AM, Recordon, David wrote:
 So please, check it out and let me know what you think...especially
 around the questions in the Editorial Comments section at the end.

Here are the issues that came up while I implemented PAPE in  
openid4java:


5.1 Request Parameters

- Is preferred_auth_policies REQUIRED? Assume yes, but not clearly  
spelled out.

- the OP MUST authenticate the End User for this request.

What if the OP / user don't want to re-authenticate, and have reasons  
to continue their session with the previous / old auth? (For example  
user changed his mind at the OP about buying the book from amazon,  
and declines the OP's request to re-authenticate).

- The OP should realize that not adhering to the request for re- 
authentication... implies there is an alternative to the above  
(other than breaking the protocol). Maybe the MUST above should be a  
SHOULD?

- (max_)auth_age is defined as numeric. Is there value for allowing  
floating-point numbers here? Would be simpler to be an integer.


5.2 Response Parameters

- auth_age: What should the value be if the OP did not actively  
authenticate the user for the current session? Suggesting unknown  
as a special value for this.

- auth_age: Since the message may spend a (not-insignificant) time  
after it's created (by the library)
before it's put on the wire
on the wire
while it's being processed by the RP
a timestamp value may be better suited here (rename it to auth_time  
maybe?). This way the RP will be able to determine the auth_age at  
any time (e.g. when it actually needs to perform the sensitive  
operation). Could use the formating used for nonces (from RFC3339).

- nist_auth_level: Numeric value - probably was meant as integer  
value.


Thanks,
Johnny

___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs


RE: OpenID Provider Authentication Policy Extension

2007-06-22 Thread =drummond.reed
Great work, David. +1 to Han's comments -- they are good points. Coming up
with a better semantic identifier for the phishing-resistant policy isn't
easy but I like his point that it really comes down to the definition that
no shared secret is available to a third party. Perhaps non-shared-secret?
omnidirectional-token?

=Drummond 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Hans Granqvist
Sent: Friday, June 22, 2007 3:50 PM
To: Recordon, David
Cc: specs@openid.net
Subject: Re: OpenID Provider Authentication Policy Extension

A few comments:

* Would be great if all the namespace URLs resolved into live links.
It always helps in the XML world and probably would in here too.

* Section 4 Defined Authentication Policies

We've talked about this before, but I just want to restate that it is
a bad idea to name a policy based on its inferred values.
Phishing-resistant implies a quality that is not necessarily
measurable. Quality can also shift over time.

The other policies are measurable (you can count number of  factors
used, for example).

I'd strongly advise renaming phishing-resistant to something like
no-secrets-shared (you can probably come up with a more succinct
term)

* 5.2 response params

Requiring openid.pape.auth_policies to have a null value if no
policies were met seems odd (and it may break processing where a value
is always expected by the parser). Better would be to explicitly state
that no policies were met by a predefined literal or URL. For example
openid.pape.auth_policies=http://schemas.openid.net/pape/policies/2007/06/no
ne

* Section 7 Examples

I wanted to see some examples on how PAPE is used in the messages.
Maybe add a few?


I like the work. However, the spec is optional. I was hoping
finalizing auth 2.0 would be top priority.

-Hans

On 6/22/07, Recordon, David [EMAIL PROTECTED] wrote:
 Over the past few weeks I've been working on the OpenID Provider
 Authentication Policy Extension which is designed to replace the work I
 did last year with the Assertion Quality Extension.

 Generally, the goal of this extension is to provide Relying Parties with
 more information about how the End User authenticated to their Provider.
 This is done by a mix of the RP requesting certain policies (such as
 phishing-resistant or multi-factor), the OP helping the End User through
 the authentication process, and then in the OpenID Authentication
 response including the policies that were met as well as optionally a
 strength level for the overall authentication.

 This extension doesn't speak at all toward trust of the End User or
 Provider, so RPs will still have to decide if they believe the
 information returned about the authentication in the response.

 So please, check it out and let me know what you think...especially
 around the questions in the Editorial Comments section at the end.

 http://openid.net/specs/openid-provider-authentication-policy-extension-
 1_0-01.html
 http://openid.net/specs/openid-provider-authentication-policy-extension-
 1_0-01.txt

 Thanks,
 --David
 ___
 specs mailing list
 specs@openid.net
 http://openid.net/mailman/listinfo/specs

___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs