Re: Requiring Pseudonymous Identifier

2009-05-14 Thread Paul Madsen

I dont think this fits either PAPE or AX.

I cant see how the privacy characteristics of an identifier are part of 
'authentication policy'. How the user authenticates to the OP is 
(mostly) orthogonal to the nature of the identifier the OP asserts.


Nor does it fit the AX description of attribute as a unit of personal 
identity information.


regards

paul

Andrew Arnott wrote:
This scenario doesn't fit what I've always felt AX was for.  I don't 
expect a fetch request to change anything about the underlying openid 
transport other than prompting the user for information disclosure at 
the OP. 

PAPE fits better in my mind.  But again, if PAPE is the only way to 
get a psuedo-anonymous identifier, then unsolicited assertions can't 
get it right.  But if we allow PAPE requests to ask for one, and for 
it to also be discoverable via the RP return_to service in its XRDS, 
then both unsolicited assertion and RP-behind-firewall scenarios work.

--
Andrew Arnott
I [may] not agree with what you have to say, but I'll defend to the 
death your right to say it. - S. G. Tallentyre



On Wed, May 13, 2009 at 4:58 PM, David Recordon da...@sixapart.com 
mailto:da...@sixapart.com wrote:


Does it make more sense to use a PAPE policy requesting a
pseudonymous identifier or an AX attribute requesting one?  Any of
these approaches would work, I just don't think we've mapped out
the pros/cons of each.

--David


On May 13, 2009, at 8:44 AM, George Fletcher wrote:

I don't think OpenID should specify how pseudonymous
identifiers are generated. That should be up to the OP. But I
like the idea of using a fixed URI as the claimed_id value to
specify the behavior desired by the RP. If, however, we need
to grow this to cover anonymous based identifiers (i.e. the
claims based models from earlier in this thread) then it might
make sense to look at a PAPE extension that covers the type of
identifier requested.

Thanks,
George

Nat Sakimura wrote:

Sorry for a slow response. This week is especially busy
for me...

I borrowed the notion from Austrian Citizen ID system.
In there, the services are divided into sectors.
A sector may span several agencies.
They call ID as PIN (Personal Identification Number).

There is a secret PIN (sPIN) which is not used anywhere
but in their SmartCard.
Then, sector sepcific PIN (ssPIN) is calculated in the
manner of :

SHA1(sPIN + SectorID)

(Note, there is a bit more details but...)

I have thrown OP secret into it.
To avoid the analytic attack, I agree that it is better to use
individual secret, as some of you
points out.

Regards,

=nat

On Tue, May 12, 2009 at 5:55 PM, Dick Hardt
dick.ha...@gmail.com mailto:dick.ha...@gmail.com wrote:

On 12-May-09, at 1:36 AM, Nat Sakimura wrote:

Reason for using RP's Subject in XRD instead of
simply using realm is
to allow for something like group identifier.

would you elaborate on the group identifier concept?


This is just one idea. Downside of this approach
is that we need to set up a WG.

I am sure there are more ideas. It might be
possible to utilize AX
so that it will only be a profile that does not
require a WG.

So shall we start discussing which direction we
want to go forward?

sure!






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


___
specs mailing list
specs@openid.net mailto: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


Re: Requiring Pseudonymous Identifier

2009-05-12 Thread Paul Madsen
there are telco use cases where a family member, by dint only of  
'subscriber authentication' to the IDP/OP, is able to access shared 
resources (e.g. family calendar) at an SP/RP.


Unlike in Chris's academia case the OP/IDP is itself unable to 
distinguish a particular user from amongst other group members based on 
this sort of authentication.


To allow the SP to indicate  back to the IDP that it needed a user 
authenticated as an individual (to allow for instance the RP to show 
calendar events associated with the user and not shared amongst the 
group) in SAML we defined an extension to Authn Context to distinguish 
between such shared credentials and those that are unique to a single user.


http://docs.oasis-open.org/security/saml/SpecDrafts-Post2.0/sstc-saml-context-ext-sc-cd-03.pdf

paul

Chris Messina wrote:
On Tue, May 12, 2009 at 10:55 AM, Dick Hardt dick.ha...@gmail.com 
mailto:dick.ha...@gmail.com wrote:



On 12-May-09, at 1:36 AM, Nat Sakimura wrote:


Reason for using RP's Subject in XRD instead of simply using
realm is
to allow for something like group identifier.


would you elaborate on the group identifier concept?


I'm not sure what Nat is specifically referring to, but there was a US 
academic institution that provided OpenIDs for classes of people... 
i.e. students, teachers, etc.


When you signed in for certain application, the OP would respond with 
the appropriate identifier for a class of users.


So, imagine I use directed identity in a school application... when I 
sign in to the OP, it will return something like 
schoolname.edu/student http://schoolname.edu/student as the identifier.


You could imagine something similar where you could use authentication 
as a way to verify that someone comes from some geographic region or 
has previously registered for certain entitlements.


Chris

--
Chris Messina
Open Web Advocate

factoryjoe.com http://factoryjoe.com // diso-project.org 
http://diso-project.org // openid.net http://openid.net // 
vidoop.com http://vidoop.com

This email is:   [ ] bloggable[X] ask first   [ ] private


___
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: Request for consideration of AX 2.0 Working Group Charter Proposal

2009-01-26 Thread Paul Madsen




FWIW, the separate 'verified' field is the approach the Infocard
community took 

https://informationcard.net/wiki/index.php/Claim_Catalog

They also allow the particular verification method used to be listed

https://informationcard.net/wiki/index.php/Claim_Catalog#Verification_Methods

One drawback of this method is that all claims sent together get lumped
together into a single bucket wrt verification

paul


Martin Atkins wrote:
Henrik
Biering wrote:
  
  Agree!

If the range of SReg attributes is expanded, however, I would suggest
to add phone number (incl. quality as suggested for email) and possibly
street+city address line(s). That would make it possible to fill in a
somewhat larger part of typical registration forms.


  
  
It might be good to apply the quality thing to all of the fields.
  
  
One approach might be to add a "verified" argument that contains a list
of names of fields that the OP has verified in some way.
  
  
However, I think the SREG spec itself needs work done since the 1.1
draft (that was never published) has a bunch of problems. It might be
better to do such work in a separate working group; I already have an
updated 1.1 draft with some of the problems from the current 1.1 draft
fixed that could potentially be used as a basis, though I'll need to
dig it out since I'm not sure what I checked it in to.
  
  
___
  
specs mailing list
  
specs@openid.net
  
http://openid.net/mailman/listinfo/specs
  
  
  


-- 
Paul Madsen
e:paulmadsen @ ntt-at.com
p:613-482-0432
m:613-282-8647
web:connectid.blogspot.com



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


Re: New OP-MultiAuth Draft Published

2009-01-18 Thread Paul Madsen




Hi David, your extension is an authentication policy declaration from
the user to the RP.

PAPE allows the RP to declare its authentication policy to the OP (and
vice versa).

I wonder if there is an opportunity for convergence? 

Or at minimum a naming scheme that hilites the commonality .. UAPE
:-)

paul

David Fuelling wrote:
For anyone interested, I've put out a 2nd draft of my
OP-MultiAuth idea. I think the first draft was pretty confusing, so
hopefully this clarifies things a bit more.
  
Wiki Page: http://wiki.openid.net/OP-MultiAuth
Actual Draft: http://wiki.openid.net/f/openid-provider-multiauth-extension-1_0-2.html
  
In a nutshell, the idea here is to protect end-users against a "rogue
OP" by providing a mechanism for a Claimed Identifier to mandate that
an RP get valid auth assertions from two or more different OP's before
giving access to RP-protected resources.
  
Thanks!
  
David
  

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

No virus found in this incoming message.
Checked by AVG. 
Version: 7.5.552 / Virus Database: 270.10.8/1899 - Release Date: 17/01/2009 5:50 PM
  


-- 
Paul Madsen
e:paulmadsen @ ntt-at.com
p:613-482-0432
m:613-282-8647
web:connectid.blogspot.com



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


Re: Use of Qworum for indirect communication

2008-12-17 Thread Paul Madsen
ion, or could it be considered in the future?  (As the lead
developer of Qworum, I can affirm that Qworum would do all it can to
facilitate this process.)

-- 
Doğa Armangil




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

  
  
  





-- 
Doğa Armangil

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

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

No virus found in this incoming message.
Checked by AVG. 
Version: 7.5.552 / Virus Database: 270.9.19/1853 - Release Date: 17/12/2008 8:31 AM
  


-- 
Paul Madsen
e:paulmadsen @ ntt-at.com
p:613-482-0432
m:613-282-8647
web:connectid.blogspot.com



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


Re: Completing the SREG 1.1 specification

2008-12-04 Thread Paul Madsen




there would appear to be an opportunity here for some drop-dead simple
cross-protocol harmonization by the larger community agreeing on the
definition of these sort of privacy policy identifiers by which a
requestor indicates its privacy commitments and the authority any
obligations.

Define the various URIs and the associated semantics, and leave it to
the particular protocols or metadata formats to define bindings.

Liberty took a first stab [1] a while back, but had/has no expectation
that the work would be meaningful if used only for Liberty/SAML
protocols.

[1] -
http://www.projectliberty.org/liberty/content/download/4323/28921/file/draft-liberty-igf-privacy-constraints-v1.0-04.pdf

paul

Dick Hardt wrote:

  On 2-Dec-08, at 3:41 PM, Allen Tom wrote:
  
  
We decided to build support for SREG before AX because SREG seems to  
be
more widely used, and also because SREG allows the RP to pass the  
url to
its privacy policy in the request. Strangely, AX does not have an
interface for the RP to pass its privacy policy to the OP.

  
  
Not sure how we missed that feature in SREG. Our bad.

  
  
Moving forward, we'd also like to support both SREG and AX, if AX is
updated to allow the privacy policy url to be included in the request.

  
  
Looking at what needs to be addressed in AX. Good suggestion. Ties in  
with suggestions from Nat where the response with the privacy policy  
is returned all signed by the OP.

  
  

I'd be happy to help contribute to SREG and AX specs if the owners of
the spec would like me to.

  
  
please!

___
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/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]

2008-11-20 Thread Paul Madsen




Dirk, typo in Sec 6

The Combined Provider SHOULD in addition obtain, from the Combined
Provider, a list .

paul

Dirk Balfanz wrote:
Ok, new spec is up: http://step2.googlecode.com/svn/spec/openid_oauth_extension/drafts/0/openid_oauth_extension.html
  
Dirk.
  
  On Mon, Nov 17, 2008 at 5:40 PM, Dirk
Balfanz [EMAIL PROTECTED]
wrote:
  [+Brian
Eaton]


On Mon, Nov 17, 2008 at 4:31 PM, Allen Tom [EMAIL PROTECTED]
wrote:

Sadly, because the OpenID authentication request is not signed, the CK
can't be authenticated, but as you pointed out, although the user may
authorize the application, the CK secret is still required to fetch the
credentials. The worst that could happen is that a user will authorize
an impostor, but the impostor will not be able to retrieve the token.
  
That being said, in our case, the CK contains additional information
besides the scope. Yahoo's OAuth Permissions screen contains a lot of
rich information including the application's name, description,
developer(s), images, authorization lifetimes, etc. Over time, new
fields may be added to the approval page.
  
While it might make sense for the application's scope to be passed in
at authorization time, does it also make sense to define new parameters
for all the other application specific metadata? The actual data that
needs to be displayed on an approval page is very SP specific, and some
SPs may have security/legal policies requiring that all metadata is
manually reviewed, which makes it impossible for metadata to be passed
in at runtime.



Oh I see. Ok. I'l make a new revision of the spec where I add a
required parameter (the consumer key) to the auth request. 

What should the spec recommend the OP should do if the consumer key and
realm don't match? Return a cancel? Return something else?

Another change I'll be making is to take out references to unregistered
consumers. Brian found a weakness in our approach (the one where we
make the association secret the consumer secret) that makes me think we
need to think about unregistered consumers a bit more[1]. 

Dirk.

[1] Basically, the problem is that we have oracles around the web that
add OAuth signatures to arbitrary requests. They're called OpenSocial
gadget containers. If and when OpenID signatures and OAuth signatures
converge, with the current propocal we might end up in a situation
where my gadget container will create OAuth signatures using the same
key needed to assert auth responses. 





So that's why SPs may need the CK in order to display the Approval
page. Make sense?
  
Allen
  
  
  
  
  
Dirk Balfanz wrote:
  

Need to know the CK for what? What purpose would hinting at the CK
serve (since it wouldn't prove ownership)? And don't say "scope" :-)

  
  
  
  




  
  
  
  

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

No virus found in this incoming message.
Checked by AVG. 
Version: 7.5.549 / Virus Database: 270.9.6/1797 - Release Date: 18/11/2008 11:23 AM
  


-- 



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


Re: PAPE Specification Review Period Commencing

2008-10-23 Thread Paul Madsen




Hi Mike, if there were an official line numbered version, it would
enable people providing comments against specific lines

Or is there another preferred mechanism for feedback?

Thanks

Paul

Mike Jones wrote:

  
  
  

  
  The OpenID Provider Authentication Policy
Extension (PAPE)
Working Group recommends approval of PAPE Draft 7 as an OpenID
Specification. The draft is available at these locations:
  http://openid.net/specs/openid-provider-authentication-policy-extension-1_0-07.html
  http://openid.net/specs/openid-provider-authentication-policy-extension-1_0-07.txt
  
  This note starts the 60 day public review period
for the
specification draft in accordance with the OpenID Foundation IPR
policies and
procedures. This review period will end on Sunday, December 21st.
Unless issues are identified during the review that the working group
believes
must be addressed by revising the draft, this review period will be
followed by
a seven day voting period during which OpenID Foundation members will
vote on
whether to approve this draft as an OpenID Specification.
  
  As background, the proposal to create the
working group,
which the membership approved, is available at http://openid.net/pipermail/specs/2008-May/002323.html.
The specifications council report on the creation of the working group
is
available at http://openid.net/pipermail/specs/2008-May/002326.html.
  
  
-- Mike
  
  
  

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

No virus found in this incoming message.
Checked by AVG. 
Version: 7.5.549 / Virus Database: 270.8.2/1739 - Release Date: 22/10/2008 7:23 AM
  


-- 



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


Re: This is user's URI for Assertion Quality Extension

2008-09-05 Thread Paul Madsen
Hi Shade, AQE has long ago been deprecated in favour of PAPE

paul

SitG Admin wrote:
 http://openid.net/specs/openid-assertion-quality-extension-1_0-03.html 
 http://openid.net/specs/openid-assertion-quality-extension-1_0-03.html
 I'd like to see the 4th draft of this include a URI level 
 authentication property.

 I'd like to know whether the OP is asserting that the user is a 
 member of Site, is this specific user *at* Site, or is a member of 
 Site and we've generated this unique Directed Identity for them that 
 won't reveal their userID at Site but will allow you, the RP, to 
 distinguish between this anonymous Site user and other anonymous Site 
 users.

 -Shade
 

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

 No virus found in this incoming message.
 Checked by AVG. 
 Version: 7.5.524 / Virus Database: 270.6.16/1651 - Release Date: 04/09/2008 
 6:57 AM
   

-- 
Paul Madsene:paulmadsen @ ntt-at.com
NTTp:613-482-0432
   m:613-282-8647
   aim:PaulMdsn5
   web:connectid.blogspot.com 

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


Re: Google OpenID is now live

2008-04-09 Thread Paul Madsen
I expect Google might have a (legal) opinion on characterizing this 
application as 'Google OpenID'

I think I'll wait for Google itself to enable my Gmail as an OpenID.

paul

Vinay Gupta wrote:
 http://openid-provider.appspot.com/

 Somebody used their app hosting service and implemented an OpenID 
 provider.

 That kind of changes things, doesn't it?

 Vinay








 -- 
 Vinay Gupta - Designer, Hexayurt Project - an excellent public domain 
 refugee shelter system
 Gizmo Project VOIP: 775-743-1851 (usually works!)  
  http://hexayurt.com/
 Cell: Iceland (+354) 869-4605   
  Skype/Gizmo/Gtalk: hexayurt 
 People with courage and character always seem sinister to the rest
   Herman Hesse


 

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

 No virus found in this incoming message.
 Checked by AVG. 
 Version: 7.5.519 / Virus Database: 269.22.9/1365 - Release Date: 4/8/2008 
 7:30 AM
   

-- 
Paul Madsene:paulmadsen @ ntt-at.com
NTTp:613-482-0432
   m:613-282-8647
   aim:PaulMdsn5
   web:connectid.blogspot.com 

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


Re: Defining PAPE active authentication (WAS: Re: PAPE Extension Specification)

2007-10-22 Thread Paul Madsen
SAML 2.0 expresses it in terms of whether or not the authentication is 
'passive'

paul

David Recordon wrote:
 Agreed with Jonathan here, don't think we need to define a policy URI  
 for active.  Rather need to clarify what is meant in section 5.1.
   (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 MUST
   authenticate the End User for this request.

 What about?
   Active authentication is defined as the user providing a credential  
 to the OP beyond a cookie which passively stores prior authentication  
 credentials.

 Still don't like that definition, but hopefully a few iterations and  
 we'll get there.  Also asking around in the security community if  
 there is a definition for this.

 --David

 On Oct 11, 2007, at 9:33 AM, Johnny Bufu wrote:

   
 On 8-Oct-07, at 4:56 PM, Jonathan Daugherty wrote:

 
 # Yep, the idea is for the PAPE spec to define a few generic and
 # agreed upon policies and then RPs and OPs can create others.  Thus
 # if there isn't agreement on a policy, there would be multiple  
 policy
 # URIs.  Same concept as in Attribute Exchange.

 Using policy URIs to indicate certain modes of authentication is a
 fine idea, but that doesn't really address the original issue: the
 spec does not define active (direct) authentication.
   
 Agreed. PAPE spec should define one such policy that's acceptable  
 for most of the OPs/RPs (and tie auth_age to it), leaving the  
 possibility open for anyone to define other similar policies.

 This could be a bit tricky to specify if there's another parameter  
 involved, but we should be able to come up with a solution.

 Johnny


 


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


   

-- 
Paul Madsen e:paulmadsen @ ntt-at.com
NTT p:613-482-0432
m:613-282-8647
aim:PaulMdsn5
web:connectid.blogspot.com 

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


of relevance to AQE

2007-02-13 Thread Paul Madsen
FYI,

It seems that that a W3C Incubator Group may be established to explore 
'Authentication Languages'

This is to be achieved by using a commonly-agreed language for 
describing authentication, along with assurance mechanisms for
statements made using the language

Initial Workshop (done): 
http://www.enisa.europa.eu/pages/authentication/auth_ws.htm
Action Plan: 
http://www.enisa.europa.eu/doc/pdf/other/authentication_action_plan.pdf

paul

-- 
Paul Madsen e:paulmadsen @ ntt-at.com
NTT p:613-482-0432
m:613-302-1428
aim:PaulMdsn5
web:connectid.blogspot.com 


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


Re: Proposal: An anti-phishing compromise

2007-02-01 Thread Paul Madsen
Hi Josh, do I understand correctly that the motivation for your proposal 
is not 'fix' the phish problem, but to simply hilite it so that RPs will 
begin to put pressure on their OPs to move to something beyond passwords?

If this is the case, perhaps allowing an SP to add it to its request for 
authentication would give a direct (and loggable)  mechanism by which 
the RP can provide feedback to the OP product managers?

Thanks

Paul

Josh Hoyt wrote:
 Hello,

 I've written up a proposal for an addition to the OpenID
 Authentication 2.0 specification that addresses the phishing problem.
 I've had some off-list discussion of it, and I think it may strike the
 right balance. Please provide feedback.

 Josh

 Background
 ==

 We have had a lot of good discussion about how phishing relates to
 OpenID. There seems to be consensus that the OpenID Authentication
 spec should address these issues, but not consensus on how that should
 happen.

 The ways that OpenID can potentially make phishing worse:

  * Redirects to your provider are a fundamental part of the flow of
 OpenID, so being redirected to a phishing site is easy to miss

  * Every relying party (necessarily) needs to know who the provider
 is in order to verify the authentication response. This means that the
 site knows what UI it needs to use to phish (and even worse, it can
 just proxy the user to the provider)

 I think these two issues cover what makes phishing potentially a
 greater threat when using OpenID.

 Although these problems are significant, if a user can authenticate to
 their OpenID provider through an non-phishable mechanism, OpenID can
 make the phishing problem *less* of a threat, because there are fewer
 places that will need to ask for credentials.

 Other relevant issues:

   * There is no universally deployed solution to the phishing problem

   * There is not even a universally *accepted* solution to the phishing 
 problem

   * Any technology that prevents phishing will require user-agent
 support or else will fundamentally change the flow of OpenID (prevent
 relying-party-initiated sign-in)

   * OpenID is intended to be deployed without requiring specific
 technologies to be present in the user-agent

   * Any general anti-phishing technology can be applied to OpenID

 Proposed Change
 ===

 Add a single, required, boolean field to the authentication response
 that specifies whether or not the method the OP used to authenticate
 the user is phishable. The specification will have to provide
 guidelines on what properties an authentication mechanism needs to
 have in order to be non-phishable. The field is just meant to
 indicate that the authentication mechanism that was used is not a
 standard secret entered into a Web form.

 Analysis
 

 This proposal is a simplification of the Assertion Quality Extension
 [1] (AQE), and is essentially the same as what Ben Laurie proposed
 earlier [2]. It does not attempt to replace the AQE or require it for
 authentication in general.

 Benefits
 

 The proposal is trivial implement, it acknowledges that phishing is a
 problem, and forces implementers think about it. If more assurances
 are required, then the AQE, whitelists, and other mechanisms still
 need to be employed. This field just sets a minimum bar.

 I think that this is the right information to require, because it
 addresses this one thing that makes OpenID potentially worse for
 security, but it does not mandate specific technologies.

 It pushes the liability for phishing relying parties to OpenID
 providers, who are the ones who should be responsible for taking
 measures to prevent phishing. IANAL, so I don't know if this has any
 real teeth, but it does make it clear to people who are implementing
 OpenID providers that it is intended to be their responsibility to
 deal with the phishing issues.

 Drawbacks
 -

 It may be tricky to define what is meant by non-phishable.

 There is no way for a Relying Party to *ensure* that the OpenID
 provider indeed uses non-phishable authentication.

 If libraries are used, the library user may not read the relevant
 parts of the specification about phishing, and so may remain ignorant
 of the phishing issues.

 Why this should be in the core spec
 ---

 I believe that this one piece of information would be required more
 often than not, given the phishing implications. The prominence of
 being in the core specification makes it harder to ignore the phishing
 problem.

 References
 ==

 1. http://openid.net/specs/openid-assertion-quality-extension-1_0-03.html
 2. http://openid.net/pipermail/general/2007-January/001340.html
 ___
 specs mailing list
 specs@openid.net
 http://openid.net/mailman/listinfo/specs


   

-- 
Paul Madsen e:paulmadsen @ ntt-at.com
NTT p:613-482-0432
m:613-302-1428

Re: Proposal: An anti-phishing compromise

2007-02-01 Thread Paul Madsen
sorry, trying to straddle worlds/terminology

OpenID  SAML
RP  == SP (Service Provider)
OP == IDP (Identity Provider)

Josh Hoyt wrote:
 On 2/1/07, Paul Madsen [EMAIL PROTECTED] wrote:
 Hi Josh, do I understand correctly that the motivation for your proposal
 is not 'fix' the phish problem, but to simply hilite it so that RPs will
 begin to put pressure on their OPs to move to something beyond 
 passwords?

 If this is the case, perhaps allowing an SP to add it to its request for
 authentication would give a direct (and loggable)  mechanism by which
 the RP can provide feedback to the OP product managers?

 What's an SP as opposed to an RP?

 Josh



-- 
Paul Madsen e:paulmadsen @ ntt-at.com
NTT p:613-482-0432
m:613-302-1428
aim:PaulMdsn5
web:connectid.blogspot.com 


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


Re: [OpenID] Assertion Quality Extension = openid.importance

2006-12-12 Thread Paul Madsen
Is there not a potential contradiction between an RP expressing both of 
'this is very very important to me' and 'I leave it to you as to the 
specifics'?

If the RP authenticated the user locally and not through OpenID, and the 
resources it was protecting were of any value or sensitivity, it would 
surely have this sort of policy over what was an acceptable mechanism. 
Does participating in OpenID mean the RP giving up this policy control? 
How many such RPs will be willing to pay this price?

Fundamentally, I don't see how acknowledging that the RP may have 
certain expectations of the authentication event is somehow in conflict 
with user-centrism.

Regards

paul

Martin Atkins wrote:
 Manger, James H wrote:
   
 The user-centric solution is not for the RP to specify a max auth age (or 
 captcha or email verification or handbio or hardotp…), but for the RP to 
 indicate the importance of the authentication. The user (with a little help 
 from their OP) decides how to react (eg whether or not to login again) based 
 on the importance/RP/auth-age/….

 

 I like this approach a lot more. It seems a lot more honest as to what's 
 really going on, and it leaves protecting the task of user's interests 
 in the IdP's hands where it belongs.



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

 No virus found in this incoming message.
 Checked by AVG Free Edition.
 Version: 7.1.409 / Virus Database: 268.15.15/581 - Release Date: 12/9/2006
   

-- 
Paul Madsen e:paulmadsen @ ntt-at.com
NTT p:613-482-0432
m:613-302-1428
aim:PaulMdsn5
web:connectid.blogspot.com 

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


Re: OpenID Signed Assertions 1.0 - Draft 1

2006-12-04 Thread Paul Madsen
://xml.resource.org/public/rfc/xml/rfc2119.xml).
[RFC3280] 	Housley, R., Polk, W., Ford, W., and D. Solo, “Internet 
X.509 Public Key Infrastructure Certificate and Certificate Revocation 
List (CRL) Profile ftp://ftp.isi.edu/in-notes/rfc3280.txt,” RFC 
3280, April 2002.
[RFC3548] 	Josefsson, S., “The Base16, Base32, and Base64 Data 
Encodings ftp://ftp.isi.edu/in-notes/rfc3548.txt,” RFC 3548, July 2003.
[W3C.REC-xmldsig-core-20020212] 	Solo, D., Eastlake, D., and J. 
Reagle, “XML-Signature Syntax and Processing 
http://www.w3.org/TR/2002/REC-xmldsig-core-20020212,” W3C 
Recommendation http://www.w3.org/TR/2002/REC-xmldsig-core-20020212, 
February 2002.




TOC #toc


  12.2. Informative References

[OASIS.saml-glossary-2.0-os] 	Hodges, J. 
mailto:[EMAIL PROTECTED], Philpott, R. 
mailto:[EMAIL PROTECTED], and E. Maler 
mailto:[EMAIL PROTECTED], “Glossary for the Security Assertion 
Markup Language (SAML) V2.0 
http://docs.oasis-open.org/security/saml/v2.0/saml-glossary-2.0-os.pdf,” 
OASIS Standard saml-glossary-2.0-os, March 2005.
[OpenID.attribute-types-1.0] 	Hardt, D. mailto:[EMAIL PROTECTED], 
“OpenID Attribute Types - Draft 02,” November 2006 (TXT 
http://www.openid.net/specs/openid-attribute-types-1_0-02.txt, HTML 
http://www.openid.net/specs/openid-attribute-types-1_0-02.html).




TOC #toc


  Author's Address

Dick Hardt
Sxip Identity
798 Beatty Street
Vancouver, BC V6B 2M1
CA
Email:  [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
URI:http://sxip.com/



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



No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.409 / Virus Database: 268.15.6/566 - Release Date: 12/3/2006
  


--
Paul Madsen e:paulmadsen @ ntt-at.com
NTT p:613-482-0432
   m:613-302-1428
   aim:PaulMdsn5
   web:connectid.blogspot.com 

Title: Draft: SAML OpenID Simple Registration Attribute Profile - Draft 1



TOC

DraftP. Madsen
NTT
ELM. Maler
Sun
November 29, 2006

SAML OpenID Simple Registration Attribute Profile - Draft 1

Abstract


	This document defines an attribute profile for SAML V2.0 for OpenID's
Simple Registration Extension 1.0.  It defines how the profile
attributes defined in the OpenID Simple Registration Extension can be
carried in SAML attributes 
  

Table of Contents

1
Requirements Notation
2
Introduction 
3
SAML OpenID Simple Registration Attribute Profile
3.1
Information
3.2
SAML Attribute Naming
3.3
Profile-Specific XML Attributes
3.4
SAML Attribute values
4
Example
5
Normative References

Authors' Addresses



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] (Bradner, B., Key words for use in RFCs to Indicate Requirement Levels, ?.) .

2
Introduction 


   This document defines an attribute profile for
   SAML V2.0 for the [OpenIDSimpleReg] (Hoyt, J., Daugherty, J., and D. Recordon, OpenID Simple Registration Extension v1, 2006.) 
  


   The OpenID Simple Registration Extension extends the OpenID Authentication Protocol to allow
for lightweight profile exchange. This attribute profile specifies
how the profile attributes defined there can be passed as SAML
attributes within SAML protocol messages.
  

3
SAML OpenID Simple Registration Attribute Profile

3.1
Information

Identification: http://www.xmlgrrl.com/ns/OpenIDSimpleReg (provisionally!)

Contact information: [EMAIL PROTECTED], [EMAIL PROTECTED]

3.2
SAML Attribute Naming

The NameFormat XML attribute in Attribute elements MUST be "http://openid.net/specs/openid-simple-registration-extension-1_0.html"

The Name XML attribute MUST be the field name as defined in [OpenIDSimpleReg] (Hoyt, J., Daugherty, J., and D. Recordon, OpenID Simple Registration Extension v1, 2006.).

3.3
Profile-Specific XML Attributes

No profile specific XML attributes are defined in this profile.

3.4
SAML Attribute values

The AttributeValue MUST be the field value, as defined in [OpenIDSimpleReg] (Hoyt, J., Daugherty, J., and D. Recordon, OpenID Simple Registration Extension v1, 2006.)

4
Example


	   Example of a SAML Attribute
	

saml:Attribute
NameFormat="http://openid.net/sp

Re: [OpenID] OpenID Assertion Quality Extension - Draft

2006-12-01 Thread Paul Madsen
Hi Avery, some minor tweaks/comments

1) the line 'the first method that the RP would like the OP to perform' 
could be interpreted as constraining the O/IDP to  performing whatever 
authentication mechanism is listed as the first in a temporal sequence, 
i.e. must do X then Y

This could be overly restrictive

2) the line 'If the two modes are considered equally strong, then it is 
the choice of the OP regarding which one or ones to authenticate 
against' could confuse, as the 'or ones' would seem to allow the OP to 
choose multiple modes from within the openid.aqe.auth_factor2

3) Suggest openid.aqe.auth_factor2 MUST NOT be present unless 
openid.aqe.auth_factor1 is present

4) The line 'If this is not specified, it is assumed that the RP is 
requesting only a single factor for authentication' in the context of 
openid.aqe.auth_factor2 should probably read

If this is not specified, it is assumed that the RP is requesting only 
a single factor for authentication (if openid.aqe.auth_factor2 is 
specified ) or not requesting a particular authentication method


paul

Avery Glasser wrote:
 Just to weigh in here...


 Paul Madsen wrote:
 Hi George, for your use case below, why would not the RP just ask 
 for the user to be up-authenticated at the desired higher level when 
 necessary?
 So in the draft... how does the RP ask for the user to be 
 up-authenticated?  The authentication request parameters do not in 
 any way indicate a previous authentication, and the extension 
 parameters also don't include any way to indicate a previous 
 authentication.  That is what I really meant by the authentications 
 being standalone.  The RP may relate the two authentications in 
 some way because it requested both.  Maybe that's good enough.
 Basically, you would require the second method with a max_age of 0 - 
 which, assuming the RP honors the request,  would tell the RP to 
 re-authenticate the user with the requested method. 


 Are you asking whether the RP should be allowed to ask the user to 
 re-present their URI in order for this to happen? And thereby 
 effectively treating each event as disconnected/standalone?
 Ideally, the user would not be able to change their URI when being 
 re-challenged based on max_auth_age but I guess the RP should make 
 sure to code for that edge case.
 Agreed - it's the RPs choice.


 Wrt combinations, I know from experience that the alternative to 
 allowing for RPs to specify combinations is a combinatorial 
 explosion in the number of  mechanism identifiers.
 I agree that the combinations can explode... but they are also 
 useful.  For example to hack my account you need both my password 
 and my hardotp. That's two secrets that need to be determined for 
 my account to be compromised. (Not that this doesn't stop phishers).


 Actually, this could be pretty simple to implement:

 Replace  openid.aqe.preferred_auth_mode with the following:

 openid.aqe.auth_factor1

 Optional: The method of authentication the RP would like the OP to 
 perform, or in the case of a multi-factor authentication, the first 
 method that the RP would like the OP to perform. The mode should match 
 one of the advertised values in the XRDS. If this is not specified, 
 then any authentication method is acceptable.

 Value: Comma-delimited list of none, password, pin, fingerbio, 
 handbio, hardotp, irisbio, otherbio, smartcard, softotp, 
 voicebio

 Note: The OP should attempt to authenticate the user with the most 
 secure mode requested. For example, if the OP has determined that 
 their voicebio method is stronger than their password method and the 
 RP requests either voicebio or password, the OP should strive to 
 authenticate the user by voicebio when possible. If the two modes 
 are considered equally strong, then it is the choice of the OP 
 regarding which one or ones to authenticate against. OPs should note 
 that authenticating a user by a non-preferred method may result in an 
 RP denying access.

 openid.aqe.auth_factor2

 Optional: In the case of a multi-factor authentication, the second 
 method that the RP would like the OP to perform. The mode should match 
 one of the advertised values in the XRDS. If this is not specified, 
 then any authentication method is acceptable. If this is not 
 specified, it is assumed that the RP is requesting only a single 
 factor for authentication. The OP will not use the same method for 
 this factor as was used in any previous factors. For example, if the 
 first factor is a password, the second factor cannot also be a password.

 Value: Comma-delimited list of none, password, pin, fingerbio, 
 handbio, hardotp, irisbio, otherbio, smartcard, softotp, 
 voicebio

 Note: The OP should attempt to authenticate the user with the most 
 secure mode requested. For example, if the OP has determined that 
 their voicebio method is stronger than their password method and the 
 RP requests either voicebio or password, the OP should strive to 
 authenticate

Re: [OpenID] OpenID Assertion Quality Extension - Draft

2006-12-01 Thread Paul Madsen
Avery, below

Avery Glasser wrote:
 Paul,

 My feedback to your feedback...


 Hi Avery, some minor tweaks/comments

 1) the line 'the first method that the RP would like the OP to 
 perform' could be interpreted as constraining the O/IDP to  
 performing whatever authentication mechanism is listed as the first 
 in a temporal sequence, i.e. must do X then Y

 This could be overly restrictive


 Actually, that is the specific intent - the RP is requesting a 
 specific order. If the OP can honor the order, that is fine. If not, 
 then the OP reports back to the RP what the order was in the response. 
 As long as the two methods are honored, then the RP should accept the 
 authentication.
If the RP specified a particular order and didn't see it come back in 
the IDP response, it has a choice, accept the assertion regardless, or 
not. If the latter, how can it indicate to the IDP in a second 
authentication request 'This time I mean it?'

I think you either say order isn't important in the request, or, if it 
is, give the IDP a mechanism to say it couldn't satisfy the order.

paul

 2) the line 'If the two modes are considered equally strong, then it 
 is the choice of the OP regarding which one or ones to authenticate 
 against' could confuse, as the 'or ones' would seem to allow the OP 
 to choose multiple modes from within the openid.aqe.auth_factor2


 Agreed. I would change that to the one - since each factor now 
 refers to a specific authentication method.

 3) Suggest openid.aqe.auth_factor2 MUST NOT be present unless 
 openid.aqe.auth_factor1 is present


 Agreed.

 4) The line 'If this is not specified, it is assumed that the RP is 
 requesting only a single factor for authentication' in the context of 
 openid.aqe.auth_factor2 should probably read

 If this is not specified, it is assumed that the RP is requesting 
 only a single factor for authentication (if openid.aqe.auth_factor2 
 is specified ) or not requesting a particular authentication method


 Agreed.


 paul


 Based on this, is there any other feedback, or shall we revise the 
 specification?

 - Avery

 Avery Glasser wrote:
 Just to weigh in here...


 Paul Madsen wrote:
 Hi George, for your use case below, why would not the RP just ask 
 for the user to be up-authenticated at the desired higher level 
 when necessary?
 So in the draft... how does the RP ask for the user to be 
 up-authenticated?  The authentication request parameters do not 
 in any way indicate a previous authentication, and the extension 
 parameters also don't include any way to indicate a previous 
 authentication.  That is what I really meant by the authentications 
 being standalone.  The RP may relate the two authentications in 
 some way because it requested both.  Maybe that's good enough.
 Basically, you would require the second method with a max_age of 0 
 - which, assuming the RP honors the request,  would tell the RP to 
 re-authenticate the user with the requested method.

 Are you asking whether the RP should be allowed to ask the user to 
 re-present their URI in order for this to happen? And thereby 
 effectively treating each event as disconnected/standalone?
 Ideally, the user would not be able to change their URI when being 
 re-challenged based on max_auth_age but I guess the RP should make 
 sure to code for that edge case.
 Agreed - it's the RPs choice.


 Wrt combinations, I know from experience that the alternative to 
 allowing for RPs to specify combinations is a combinatorial 
 explosion in the number of  mechanism identifiers.
 I agree that the combinations can explode... but they are also 
 useful.  For example to hack my account you need both my password 
 and my hardotp. That's two secrets that need to be determined 
 for my account to be compromised. (Not that this doesn't stop 
 phishers).


 Actually, this could be pretty simple to implement:

 Replace  openid.aqe.preferred_auth_mode with the following:

 openid.aqe.auth_factor1

 Optional: The method of authentication the RP would like the OP to 
 perform, or in the case of a multi-factor authentication, the first 
 method that the RP would like the OP to perform. The mode should 
 match one of the advertised values in the XRDS. If this is not 
 specified, then any authentication method is acceptable.

 Value: Comma-delimited list of none, password, pin, 
 fingerbio, handbio, hardotp, irisbio, otherbio, 
 smartcard, softotp, voicebio

 Note: The OP should attempt to authenticate the user with the most 
 secure mode requested. For example, if the OP has determined that 
 their voicebio method is stronger than their password method and the 
 RP requests either voicebio or password, the OP should strive to 
 authenticate the user by voicebio when possible. If the two modes 
 are considered equally strong, then it is the choice of the OP 
 regarding which one or ones to authenticate against. OPs should note 
 that authenticating a user by a non-preferred method may result in 
 an RP

Re: [OpenID] OpenID Assertion Quality Extension - Draft

2006-11-30 Thread Paul Madsen
Hi George, for your use case below, why would not the RP just ask for 
the user to be up-authenticated at the desired higher level when necessary?

Are you asking whether the RP should be allowed to ask the user to 
re-present their URI in order for this to happen? And thereby 
effectively treating each event as disconnected/standalone?

Wrt combinations, I know from experience that the alternative to 
allowing for RPs to specify combinations is a combinatorial explosion in 
the number of  mechanism identifiers.

Paul

George Fletcher wrote:
 +1 simple and straight forward

 Just curious about uses cases where the required authentication level 
 changes over time.  For instance, a use case where to view my stock 
 portfolio just requires password, but doing a trade requires 
 voicebio.  Is the expectation that authentication events can be 
 treated as standalone? or that it's the RP's responsibility to manage 
 the combinations based on the identifier?

 One final question... Is it valuable to provide a way to request two or 
 more authentication methods be employed in the authentication event?  
 For example, administrators of a site must use both password and 
 hardotp.  Everyone else just needs password.

 Thanks,
 George


 ___
 general mailing list
 [EMAIL PROTECTED]
 http://openid.net/mailman/listinfo/general


   

-- 
Paul Madsen e:paulmadsen @ ntt-at.com
NTT p:613-482-0432
m:613-302-1428
aim:PaulMdsn5
web:connectid.blogspot.com 

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