Network Working Group M. Wahl Internet-Draft Informed Control Inc. Intended status: Standards Track February 27, 2007 Expires: August 31, 2007 Enrolled User Policy Profiles Attribute draft-wahl-schema-eupp-attribute-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 31, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Wahl Expires August 31, 2007 [Page 1] Internet-Draft Enrolled User Policy Profiles Attribute February 2007 Abstract This document defines an attribute of a user identity which contains a list of the identifiers of enrollment policy profiles for that user. This attribute is generated by an identity provider that manages the user's identity. An encoding of the attribute is defined for transport in the Lightweight Directory Access Protocol (LDAP), in the Security Assertion Markup Language (SAML), the OpenID Attribute Exchange Protocol, and as an Information Card claim. Wahl Expires August 31, 2007 [Page 2] Internet-Draft Enrolled User Policy Profiles Attribute February 2007 1. Introduction In an identity metasystem [15], when an end user requests access to a service, the network interactions for authenticating and authorizing that user can involve three parties: a relying party, an identity provider, and the end user. The relying party is the network entity which requires the identity of a user in order to make an access control decision. The identity provider is the network entity which establishes the identity of the end user. For example, a company which provides a free blog hosting service to the Internet might operate as an identity provider. When a customer of the service logs in to update their blog, the company will authenticate the user and record the last login time. Another Internet service, such as a free digital photo hosting service, might act as relying party and leverage that blog hosting service identity provider. An identity provider - relying party relationship between these two organizations will enable a customer of that blog hosting service to be able to access the digital photo hosting service without needing to maintain a separate copy of their account authentication credentials at the digital photo hosting service. A relying party can make use of claims issued by an identity provider in order to determine whether the user requesting access to a service has been authenticated, and if so, whether access should be granted. Whether the relying party will permit access depends on the relying party's access control decision function. One input to that function is an assessment on the reliability of the information provided in those claims, which might be based on the practices and procedures employed by the identity provider which led to those claims being generated. Another input is the suitability of the identity and the associated claims to the service provided by the relying party. In order to assist the relying party with this decision, the identity provider might wish to indicate under which set of practices the user's identity is managed (their identity as known to the identity provider was established or revised), particularly if the identity provider has multiple practices for enrollment, or these practices change over time. In a typical deployment, the identity provider and relying party have a relationship established before a user identified by the identity provider is allowed access to a relying party. The specifications agreed in that relationship might include, for example, the community of users served by the identity provider, the practices by which identity provider identifies and authenticates users, or the formats of the attributes generated by the identity provider. In some cases, an identity provider might offer claim generation Wahl Expires August 31, 2007 [Page 3] Internet-Draft Enrolled User Policy Profiles Attribute February 2007 services to user community that includes multiple, potentially overlapping, categories of users. The identification of the category of user might be of interest to the relying parties in order to enable the relying party to make a better access control decision. To continue the previous example, the blog hosting service might have a policy that all of their employees have accounts in the service, and that individuals whose employment is terminated are allowed to keep their blog hosting accounts. The blog hosting service might wish to indicate to the relying parties whether the user's account is for o a current employee o a former employee o a user with no employment history with the identity provider The degree of verification used to establish the user's account might potentially be greater for current and former employees than for non- employee users (e.g., if the employee process incorporated an in- person identity document verification process), and the degree of authentication used to identify the requestor as a user might be greater for current employees than for former employees or non- employee users (e.g., if current employees are required to perform multi-factor authentication, but other users simply rely on password- based authentication). Frequently, these categorizations are connected with the different communities of users supported by the identity provider. A large company operating an in-house identity provider might have multiple categories of individuals accessing their internal network, such as employees, contractors, employees and contractors of outsourced service providers, auditors, employees and contractors of partners and customers, etc. The company will have different policies for how each category of user that is enrolled into the identity provider service. Even for customers or employees as a whole, the enrollment practices that an identity provider follows may change over time. For example, regulation might require that the identity provider use stronger verification methods for new customers. This document defines an attribute of a user identity that is intended for use in an identity metasystem, for an identity provider to specify the enrolled user policy or policies which establish and maintain the user identity at that identity provider. Wahl Expires August 31, 2007 [Page 4] Internet-Draft Enrolled User Policy Profiles Attribute February 2007 The words "MUST", "SHOULD" and "MAY" are used as defined in RFC 2119 [1]. Please send comments to the author at mark.wahl@informed-control.com. Wahl Expires August 31, 2007 [Page 5] Internet-Draft Enrolled User Policy Profiles Attribute February 2007 2. Attribute definition This document defines an attribute of a user identity that is generated by an identity provider to specify the enrolled user policy profiles under which the user's identity is managed by the identity provider. The value of an attribute of this type consists of an ordered list of one or more enrolled user policy profile identifiers. Each identifier specifies a single enrolled user policy profile supported by the identity provider, under which the user was enrolled into the identity provider's user community. If this attribute is present in a user's identity and more than one enrolled user policy profile identifier is present in the value of the attribute, then all of the enrolled user policy profiles identified in that value apply to the identity. 2.1. Enrolled user policy profile An enrolled user policy profile is a named set of rules that indicates the applicability of a user identity to a particular community and/or class of application with common security requirements. An enrolled user policy profile for a user may be based on the practices of the identity provider, on the user community served by the identity provider, on the credentials by which the user established their identity with the identity provider, or other factors. This policy is similar in concept to a certificate policy, which is defined in X.509 [16] and expanded in RFC 3647 [2]. An identity provider can categorize a user's identity into zero, one, or more than one enrolled user policy profiles. There may be multiple enrolled user policy profiles by which a particular user is categorized, and this set may change over time. However, an enrolled user policy profile is not intended to change to indicate a transitory state that is still within conditions acceptable to the identity provider. Other protocols, such as the OpenID assertion quality extension [17], SHOULD be used to indicate parameters that change, such as the authentication method most recently selected by a user. 2.2. Enrolled user policy profile identifier forms An enrolled user policy profile is named by a Uniform Resource Identifier [3] (URI). The URI MUST be encoded into US-ASCII characters, and any embedded whitespace MUST be encoded. URIs MUST be normalized by the identity provider generating them, to enable relying parties to compare two URIs for equality using a US ASCII case exact match string comparison function. While a value of the attribute can contain URIs that are URNs or URLs Wahl Expires August 31, 2007 [Page 6] Internet-Draft Enrolled User Policy Profiles Attribute February 2007 of any scheme, the identity provider SHOULD use URIs that are either of the OBJECT IDENTIFIER identifier form, or the HTTP identifier form, as described below. 2.2.1. OBJECT IDENTIFIER identifier form choice The OBJECT IDENTIFIER identifier form of an enrolled user policy profile identifier is intended for use by an identity provider that is also a X.509 certification authority (CA) or registration authority (RA). A CA or RA already might have a OBJECT IDENTIFIER that specifies the certificate policy by which an end user certificate is issued, for use in the Internet X.509 Public Key Infrastructure [4]. The URI of the enrolled user policy profile identifier consists of a Uniform Resource Name in the "oid" namespace [5]. A URI in this form will resemble urn:oid:1.3.6.1.2.1.27 2.2.2. HTTP identifier form choice The HTTP identifier form of an enrolled user policy profile identifier is intended for use by any identity provider. The URI of the enrolled user policy profile identifier consists of a Uniform Resource Locator in either the "http" [6] or "https" [7] schemes. The URI MAY contain a query, and MAY contain a fragment. Wahl Expires August 31, 2007 [Page 7] Internet-Draft Enrolled User Policy Profiles Attribute February 2007 3. Representing the attribute in an identity metasystem The value of an attribute of this type consists of an ordered list of one or more enrolled user policy profile identifiers. Each enrolled user policy profile is identified by a URI, as discussed in the previous section, and are separated in the enrolled user policy profile identifiers value from other URIs by a US-ASCII space character (SP). 3.1. Representation as an LDAP attribute This attribute can be part of a user's entry held in a directory server based on the LDAP [8] data model. The schema definitions are based on the LDAP directory information models [9]. The attribute type is defined as follows (with lines wrapped for readability): attributeTypes: ( 1.3.6.1.4.1.21008.97.74.4.1 NAME 'enrolledUserPolicyProfiles' EQUALITY caseExactMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE ) The caseExactMatch and Directory String syntax are defined in RFC 4517 [10]. In order to allow this class to be present on objects of many different structural classes, an auxiliary object class is defined. objectClasses: ( 1.3.6.1.4.1.21008.97.74.4.2 NAME 'enrolledUserPolicyProfilesClass' AUXILIARY MAY ( enrolledUserPolicyProfiles ) ) This auxiliary class might most usefully be combined with the person object class. Clients MUST NOT assume the absence of this class in an entry's objectClass implies that the enrolledUserPolicyProfiles attribute is not present in the entry, as this attribute might be part of a privately-defined schema object class, or be provided through collective attributes. Wahl Expires August 31, 2007 [Page 8] Internet-Draft Enrolled User Policy Profiles Attribute February 2007 3.2. Representation as a SAML 1.1 attribute This attribute can be expressed as a SAML 1.1 attribute. The attribute is represented as if it is translated from LDAP to SAML 1.1 using the method described in the MAC-Dir SAML Attribute Profile [11]. In this representation, the SAML attribute name is urn:oid:1.3.6.1.4.1.21008.97.74.4.1 The AttributeNamespace is urn:mace:shibboleth:1.0:attributeNamespace:uri An example SAML 1.1 attribute is https://www.example.com/policy/cur.html#pfc urn:oid:1.1 3.3. Representation as a SAML 2.0 attribute This attribute can be expressed as a SAML 2.0 attribute. The attribute is represented as if it is translated from LDAP to SAML 2.0 using the method described in the SAML V2.0 X.500/LDAP Attribute Profile [12]. In this representation, the SAML attribute name is urn:oid:1.3.6.1.4.1.21008.97.74.4.1 The FriendlyName is "enrolledUserPolicyProfiles". The attribute NameFormat is urn:oasis:names:tc:SAML:2.0:attrname-format:uri 3.4. Representation in OpenID Attribute Exchange This attribute can be transferred using the OpenID Attribute Exchange protocol [13]. Wahl Expires August 31, 2007 [Page 9] Internet-Draft Enrolled User Policy Profiles Attribute February 2007 The attribute type identifier URI is http://www.ldap.com/1/schema/eupp/enrolledUserPolicyProfiles The data format URI is http://www.ldap.com/1/schema/eupp/spaceSeparatedUriList The data type is 3.5. Representation as an Information Card claim This attribute can be expressed as an Information Card claim [14]. The claim type URI is http://www.ldap.com/1/schema/eupp/enrolledUserPolicyProfiles The data type is "xs:string". Wahl Expires August 31, 2007 [Page 10] Internet-Draft Enrolled User Policy Profiles Attribute February 2007 4. Sample identifiers This section provides sample categories of enrolled user policy profiles. 4.1. Unverified The URI "http://www.ldap.com/1/schema/eupp/id/unverified.rdf" indicates that the identity provider has not performed any verification of the identity. 4.2. Provisional The URI "http://www.ldap.com/1/schema/eupp/id/provisional.rdf" indicates that the identity provider has not completed performing the verification tasks which are normally performed for a new user enrollment. 4.3. Shared account The URI "http://www.ldap.com/1/schema/eupp/id/shared.rdf" indicates that the identity is known by the identity provider to be used as a shared account by a potentially large number of users. 4.4. Fictitious The URI "http://www.ldap.com/1/schema/eupp/id/fictitious.rdf" indicates that the identity is known by the identity provider to be a fictitious persona, e.g. if the user has registered with a name of "Mickey Mouse". Wahl Expires August 31, 2007 [Page 11] Internet-Draft Enrolled User Policy Profiles Attribute February 2007 5. Security Considerations As with the certificate policy defined in RFC 3647 [2], the enrolled user policy profiles attribute MAY be used by a relying party to help in deciding whether an identity is sufficiently trustworthy and otherwise appropriate for a particular application. This attribute is purely advisory and is provided voluntarily by the identity provider. This attribute in itself is not sufficient for a relying party to establish trust in an identity provider, or for a relying party to establish trust in a particular identity: additional attributes and trust mechanisms are required, that are outside of the scope of this document. Wahl Expires August 31, 2007 [Page 12] Internet-Draft Enrolled User Policy Profiles Attribute February 2007 6. IANA Considerations The LDAP attribute and object class defined in this document will be registered with IANA. Subject: Request for LDAP Descriptor Registration Descriptor (short name): enrolledUserPolicyProfiles Object Identifier: 1.3.6.1.4.1.21008.97.74.4.1 Person & email address to contact for further information: Mark Wahl Usage: attribute type Specification: RFC XXXX Author/Change Controller: IESG Comments: Subject: Request for LDAP Descriptor Registration Descriptor (short name): enrolledUserPolicyProfilesClass Object Identifier: 1.3.6.1.4.1.21008.97.74.4.2 Person & email address to contact for further information: Mark Wahl Usage: object class Specification: RFC XXXX Author/Change Controller: IESG Comments: Wahl Expires August 31, 2007 [Page 13] Internet-Draft Enrolled User Policy Profiles Attribute February 2007 7. References 7.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP 14, March 1997. [2] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S. Wu, "Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework", RFC 3647, November 2003. [3] Berners-Lee, T., "Uniform Resource Identifier (URI): Generic Syntax", RFC 1738, STD 66, January 2005. [4] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002. [5] Mealling, M., "A URN Namespace of Object Identifiers", RFC 3061, February 2001. [6] "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [7] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [8] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP): Technical Specification Road Map", RFC 4510, June 2006. [9] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP): Directory Information Models", RFC 4512, June 2006. [10] Legg, S., "LDAP: Syntaxes and Matching Rules", RFC 4517, June 2006. [11] Cantor, S. and K. Hazelton, "MACE-Dir SAML Attribute Profile", April 2006. [12] Cantor, S., "SAML V2.0 X.500/LDAP Attribute Profile", December 2006. [13] Hardt, D. and J. Bufu, "OpenID Attribute Exchange 1.0 - Draft 4", January 2007. [14] Nanda, A., "A Technical Reference for the Information Card Profile V1.0", December 2006. Wahl Expires August 31, 2007 [Page 14] Internet-Draft Enrolled User Policy Profiles Attribute February 2007 7.2. Informative References [15] Microsoft Corporation, "Microsoft's Vision for an Identity Metasystem", May 2005. [16] "ISO/IEC 9594-8/ITU-T Recommendation X.509, "Information Technology - Open Systems Interconnection: The Directory: Authentication Framework"", 1997. [17] Recordon, D., Glasser, A., and P. Madsen, "OpenID Assertion Quality Extension 1.0 - Draft 3", December 2006. Wahl Expires August 31, 2007 [Page 15] Internet-Draft Enrolled User Policy Profiles Attribute February 2007 Appendix A. Copyright Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Wahl Expires August 31, 2007 [Page 16] Internet-Draft Enrolled User Policy Profiles Attribute February 2007 Author's Address Mark Wahl Informed Control Inc. PO Box 90626 Austin, TX 78709 US Email: mark.wahl@informed-control.com Wahl Expires August 31, 2007 [Page 17] Internet-Draft Enrolled User Policy Profiles Attribute February 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Wahl Expires August 31, 2007 [Page 18]