Re: Requiring Pseudonymous Identifier
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
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
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
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
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
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]
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
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
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
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)
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
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
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
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 Signed Assertions 1.0 - Draft 1
://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
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
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
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
