Re: [specs-pape] Typo in the PAPE spec?

[Paul Madsen]

are examples normative? If not, is an errata necessary?

Are there any plans for another PAPE version?

paul

John Bradley wrote:

The normative text is correct.

It was always openid.pape.preferred_auth_level_types form Oct 2008 
when it was added to draft 5.

The bad example crept in in Draft 6 and went unnoticed.

We will need to figure out a process for errata.

Thanks for picking it up.

John B.
On 17-Jun-09, at 1:03 PM, Allen Tom wrote:


Hi All,

In Section 5.1 of the PAPE Spec, there's a request parameter defined 
called

   openid.pape.preferred_auth_level_types

however the example in the same section calls it

   openid.pape.preferred_auth_levels

Which one is it?


Thanks
___
specs-pape mailing list
specs-p...@openid.net
http://openid.net/mailman/listinfo/specs-pape


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


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

Re: Requiring Pseudonymous Identifier

[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 > 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
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 
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
  
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: Requiring Pseudonymous Identifier

[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 > 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  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  // diso-project.org 
 // openid.net  // 
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

[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

[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

[Paul Madsen]

@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

[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]

[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

[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

[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

[Paul Madsen]

if and when Google manages its own namespace as OpenIDs, I hope they 
provide more consistent QoS - I havent seen this one work yet

paul

Vinay Gupta wrote:
>
> I think that kind of misses the point. The *namespace* that google 
> manages is now open for business as an OpenID provider. It's an 
> unanticipated side-effect of the APIs.
>
> I think it's kind of a big deal, actually, in terms of how OpenID is 
> right from an engineering perspective and how it can spread in 
> unexpected ways. If only login were so easy.
>
> 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
>
>
> On Apr 9, 2008, at 7:45 PM, John Ehn wrote:
>> I agree.  I think this is an excellent technology demonstration, but 
>> it is a third-party, not Google, that is enabling the ID.
>>  
>> John
>>
>> 2008/4/9 Immad Akhund <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>:
>>
>> When Google eventually does make a proper OpenID provider all the
>> OpenIDs provided by openid-provider.appspot.com
>> <http://openid-provider.appspot.com/> would not match.
>>
>> Would get very confusing apart from advanced users that
>> understand the distinction.
>>
>> Immad
>>
>>
>> On Wed, Apr 9, 2008 at 12:49 PM, Paul Madsen
>> <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote:
>>
>> 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 <mailto: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
>> <http://ntt-at.com/>
>> NTTp:613-482-0432
>>   m:613-282-8647
>>   aim:PaulMdsn5
>>   web:connectid.blogspot.com
>> <http://connectid.blogspot.com/>
>>
>> ___
>> specs mailing list
>> specs@openid.net <mailto:specs@openid.net>
>> http://openid.net/mailman/listinfo/specs
>>
>>
>>
>>
>> -- 
>> Cell: +1 617 460 7271
>> Skype: i.akhund
>>     Blog: http://immadsnewworld.com 

Re: Google OpenID is now live

[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: OpenID 3.0

[Paul Madsen]

in a B2B case, would not the insurance agency be the OP, and its 
identity carried through the relevant assertion fields?

As Masaki-san points out, the RP can base its authorization decision on 
any number of factors - some of which might be carried through OpenID, 
some not. In this sense, OpenID is already 'converged' with 
authorization, as an RP already bases its authz decision on the asserted 
identifier. Allowing for the protocol to carry other attributes that 
might also feed into the decision is just an enhancement.

Theoretically possible would be for the OP assertion to actually carry 
an 'authorization statement' expressing some set of privileges the user 
should enjoy at the RP (and that the RP would respect). Possible, but 
weird because of the implied loss of sovereignty for the RP.

paul

McGovern, James F (HTSC, IT) wrote:
>  If you were going to use OpenID in a B2B scenario where an insurance
> agent want to access an insurance carriers web site, the identity
> provider would need to not only pass the identity of the agent but also
> the insurance agency, the insurance agent is employed by.
>
> -Original Message-
> From: NISHITANI Masaki [mailto:[EMAIL PROTECTED] 
> Sent: Tuesday, February 26, 2008 1:10 AM
> To: McGovern, James F (HTSC, IT)
> Cc: specs@openid.net
> Subject: Re: OpenID 3.0
>
> Let me confirm a point.
>
> On #1, do you mean to enforce OpenID to control the identity-holders are
> permitted to access what kind of content or service on RP or provide
> some kind of help making 
>RP's decision easier?
>
> I feel it is natural for RP to do access-control be itself, but on the
> other hand, any information which describes what kind of person the
> accessing web-user is, will be welcome for RPs such as gender, age or
> any kind of attributes.
>
> McGovern, James F wrote:
>   
>> Figured I would ask if anyone is interested in brainstorming the next 
>> version of OpenID and how it can be used in Enterprise B2B settings 
>> and not solely focusing on consumerish interactions. Some things that 
>> I would like to see in the next version are:
>>
>> 1. A discussion on how AuthZ can converge with OpenID 2. Modeling of 
>> relationships 3. Not allowing an OpenID to be a vector for SQL 
>> Injection and putting something around what it should look like 4. A 
>> way to indicate to the relying party what level of authentication has 
>> occurred such as did the OP check a password, how did it validate a 
>> user. Without this, there is no way that a trust model could be 
>> established in a credible way.
>>
>> 5. A way for OpenID relying parties to filter out Ops. In a business 
>> scenario, if I run the Sun employee store, I may only want the Sun OP 
>> to talk with me.
>>
>>
>>
>> **
>> *** This communication, including attachments, is for the exclusive 
>> use of addressee and may contain proprietary, confidential and/or 
>> privileged information. If you are not the intended recipient, any 
>> use, copying, disclosure, dissemination or distribution is strictly 
>> prohibited. If you are not the intended recipient, please notify the 
>> sender immediately by return e-mail, delete this communication and 
>> destroy all copies.
>> **
>> ***
>>
>>
>> --
>> --
>>
>> ___
>> specs mailing list
>> specs@openid.net
>> http://openid.net/mailman/listinfo/specs
>> 
>
>
>
> *
> This communication, including attachments, is
> for the exclusive use of addressee and may contain proprietary,
> confidential and/or privileged information.  If you are not the intended
> recipient, any use, copying, disclosure, dissemination or distribution is
> strictly prohibited.  If you are not the intended recipient, please notify
> the sender immediately by return e-mail, delete this communication and
> destroy all copies.
> *
>
> ___
> 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

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

[Paul Madsen]

Hey David, IsPassive is an attribute on the AuthnRequest that allows the 
SP to indicate policy for how the user is authenticated

IsPassive [Optional]

A Boolean value. If "true", the identity provider and the user agent 
itself MUST NOT visibly take control
of the user interface from the requester and interact with the presenter 
in a noticeable fashion. If a
value is not provided, the default is "false".

It works in combination with ForceAuthn (which seems to fit with where 
you wre going with 'active authn' below

ForceAuthn [Optional]

A Boolean value. If "true", the identity provider MUST authenticate the 
presenter directly rather than
rely on a previous security context. If a value is not provided, the 
default is "false". However, if both
ForceAuthn and IsPassive are "true", the identity provider MUST NOT 
freshly authenticate the
presenter unless the constraints of IsPassive can be met

David Recordon wrote:
> Hey Paul,
> How do you guys define "passive".  Seems like the opposite problem of 
> defining "active".
>
> Thanks,
> --David
>
> On Oct 22, 2007, at 3:18 PM, Paul Madsen wrote:
>
>> 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
>>
>
>
>
>

-- 
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

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

[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

[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

[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: Proposal: An anti-phishing compromise

[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 cor

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

[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

[Paul Madsen]

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  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  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
	


  
[EMAIL PROTECTED]
  


 TOC 
5. Normative References

[OpenIDSimpleReg]
Hoyt, J., Daugherty, J., and D. Recordon, “OpenID Simple Registration Extension v1,” 2006.
[RFC2119]
Bradner, B., “Key words for use in RFCs to Indicate Requirement Levels,” RFC 2119, ?.



 TOC 
Authors' Addresses

 
Paul Madsen
 
NTT
Email: 
[EMAIL PROTECTED]
  
 
Eve Maler
 
Sun Microsystems, Inc.
Email: 
[EMAIL PROTECTED]





http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"; >

]>

Re: [OpenID] OpenID Assertion Quality Extension - Draft

[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 

Re: [OpenID] OpenID Assertion Quality Extension - Draft

[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 a

Re: [OpenID] OpenID Assertion Quality Extension - Draft

[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