--- 1/draft-ietf-scim-core-schema-12.txt 2014-11-14 21:15:02.084050732 -0800 +++ 2/draft-ietf-scim-core-schema-13.txt 2014-11-14 21:15:02.204053661 -0800 @@ -1,23 +1,23 @@ Network Working Group P. Hunt, Ed. Internet-Draft Oracle Intended status: Standards Track K. Grizzle -Expires: April 20, 2015 SailPoint +Expires: May 18, 2015 SailPoint E. Wahlstroem Nexus Technology C. Mortimore Salesforce - October 17, 2014 + November 14, 2014 System for Cross-Domain Identity Management: Core Schema - draft-ietf-scim-core-schema-12 + draft-ietf-scim-core-schema-13 Abstract The System for Cross-Domain Identity Management (SCIM) specifications are designed to make identity management in cloud based applications and services easier. The specification suite builds upon experience with existing schemas and deployments, placing specific emphasis on simplicity of development and integration, while applying existing authentication, authorization, and privacy models. Its intent is to reduce the cost and complexity of user management operations by @@ -38,21 +38,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." - This Internet-Draft will expire on April 20, 2015. + This Internet-Draft will expire on May 18, 2015. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -72,35 +72,35 @@ 2.1.1. String . . . . . . . . . . . . . . . . . . . . . . . 6 2.1.2. Boolean . . . . . . . . . . . . . . . . . . . . . . . 6 2.1.3. Decimal . . . . . . . . . . . . . . . . . . . . . . . 6 2.1.4. Integer . . . . . . . . . . . . . . . . . . . . . . . 6 2.1.5. DateTime . . . . . . . . . . . . . . . . . . . . . . 7 2.1.6. Binary . . . . . . . . . . . . . . . . . . . . . . . 7 2.1.7. Reference . . . . . . . . . . . . . . . . . . . . . . 7 2.1.8. Complex . . . . . . . . . . . . . . . . . . . . . . . 7 2.2. Multi-valued Attributes . . . . . . . . . . . . . . . . . 8 2.3. Unassigned and Null Values . . . . . . . . . . . . . . . 8 - 3. SCIM Resources . . . . . . . . . . . . . . . . . . . . . . . 8 + 3. SCIM Resources . . . . . . . . . . . . . . . . . . . . . . . 9 3.1. Common Attributes . . . . . . . . . . . . . . . . . . . . 11 3.2. Defining New Resource Types . . . . . . . . . . . . . . . 12 3.3. Attribute Extensions to Resources . . . . . . . . . . . . 12 4. SCIM Core Resources and Extensions . . . . . . . . . . . . . 13 4.1. User Resource Schema . . . . . . . . . . . . . . . . . . 13 4.1.1. Singular Attributes . . . . . . . . . . . . . . . . . 13 4.1.2. Multi-valued Attributes . . . . . . . . . . . . . . . 16 4.2. Group Resource Schema . . . . . . . . . . . . . . . . . . 18 4.3. Enterprise User Schema Extension . . . . . . . . . . . . 19 - 5. Service Provider Configuration Schema . . . . . . . . . . . . 19 - 6. ResourceType Schema . . . . . . . . . . . . . . . . . . . . . 21 - 7. Schema Definition . . . . . . . . . . . . . . . . . . . . . . 22 - 8. JSON Representation . . . . . . . . . . . . . . . . . . . . . 25 - 8.1. Minimal User Representation . . . . . . . . . . . . . . . 25 + 5. Service Provider Configuration Schema . . . . . . . . . . . . 20 + 6. ResourceType Schema . . . . . . . . . . . . . . . . . . . . . 22 + 7. Schema Definition . . . . . . . . . . . . . . . . . . . . . . 23 + 8. JSON Representation . . . . . . . . . . . . . . . . . . . . . 26 + 8.1. Minimal User Representation . . . . . . . . . . . . . . . 26 8.2. Full User Representation . . . . . . . . . . . . . . . . 26 8.3. Enterprise User Extension Representation . . . . . . . . 29 8.4. Group Representation . . . . . . . . . . . . . . . . . . 32 8.5. Service Provider Configuration Representation . . . . . . 33 8.6. Resource Type Representation . . . . . . . . . . . . . . 35 8.7. Schema Representation . . . . . . . . . . . . . . . . . . 35 9. Security Considerations . . . . . . . . . . . . . . . . . . . 58 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 59 10.1. New Registration of SCIM URN Sub-namespace . . . . . . . 59 10.2. URN Sub-Namespace for SCIM . . . . . . . . . . . . . . . 59 @@ -349,25 +349,29 @@ and has a mutability of "immutable". value The attribute's significant value; e.g., the e-mail address, phone number, etc. $ref The reference URI of the target resource, if the attribute is a reference. When returning multi-valued attributes, service providers SHOULD canonicalize the value returned, if appropriate (e.g. for e-mail - addresses and URLs). Service providers MAY return the same value - more than once with different types (e.g. the same e-mail address may - used for work and home), but SHOULD NOT return the same (type, value) - combination more than once per Attribute, as this complicates - processing by the Consumer. + addresses and URLs). Service providers MAY return the canonicalized + value using the "display" sub-attribute and return the original value + using the "value" attribute. + + Service providers MAY return the same value more than once with + different types (e.g. the same e-mail address may used for work and + home), but SHOULD NOT return the same (type, value) combination more + than once per Attribute, as this complicates processing by the + Consumer. 2.3. Unassigned and Null Values Unassigned attributes, the null value, or empty array (in the case of a multi-valued attribute) SHALL be considered to be equivalent in "state". Assigning an attribute with the value "null" or an empty array (in the case of multi-valued attributes) has the effect of making the attribute "unassigned". When a resource is expressed in JSON form, unassigned attributes, though they are defined in schema, MAY be omitted for compactness. @@ -430,21 +435,21 @@ attributes "employeeNumber" and "costCenter" which are contained in their own JSON sub-structure identified by their schema URI. Some values have been omitted (...), shortened or spaced out for clarity. { "schemas": [ "urn:ietf:params:scim:schemas:core:2.0:User", "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User"], "id": "2819c223-7f76-453a-413861904646", - "externalId": ["701984"], + "externalId": "701984", "userName": "bjensen@example.com", "name": { "formatted": "Ms. Barbara J Jensen III", "familyName": "Jensen", "givenName": "Barbara", "middleName": "Jane", "honorificPrefix": "Ms.", "honorificSuffix": "III" }, @@ -708,29 +713,34 @@ and the ability to update or set passwords are out of scope of this document. The mutability of this attribute is "writeOnly" indicating the value MUST NOT be returned by a service provider in any form. 4.1.2. Multi-valued Attributes The following multi-valued attributes are defined. emails - E-mail addresses for the User. The value SHOULD be canonicalized - by the service provider, e.g. "bjensen@example.com" instead of - "bjensen@EXAMPLE.COM". Canonical type values of "work", "home", - and "other". + E-mail addresses for the User. The value SHOULD be specified + according to [RFC5321]. Service providers SHOULD canonicalize the + value according to [RFC5321], e.g. "bjensen@example.com" instead + of "bjensen@EXAMPLE.COM". Ths "display" sub-attribute MAY be used + to return the canonicalized representation of the e-mail value. + Canonical type values of "work", "home", and "other". phoneNumbers - Phone numbers for the user. The value SHOULD be canonicalized by - the service provider according to format in [RFC3966] e.g. - 'tel:+1-201-555-0123'. Canonical type values of "work", "home", + Phone numbers for the user. The value SHOULD be specified + according to the format in [RFC3966] e.g. 'tel:+1-201-555-0123'. + Service providers SHOULD canonicalize the value according to + [RFC3966] format, when appropriate. The "display" sub-attribute + MAY be used to return the canonicalized representation of the + phone number value. Canonical type values of "work", "home", "mobile", "fax", "pager", and "other". ims Instant messaging address for the user. No official canonicalization rules exist for all instant messaging addresses, but service providers SHOULD, when appropriate, remove all whitespace and convert the address to lowercase. Instead of the standard canonical values for type, this attribute defines the following canonical values to represent currently popular IM services: "aim", "gtalk", "icq", "xmpp", "msn", "skype", "qq", @@ -1206,21 +1216,21 @@ Figure 3: Example Minimal User JSON Representation 8.2. Full User Representation The following is a non-normative example of the fully populated SCIM representation in JSON format. { "schemas": ["urn:ietf:params:scim:schemas:core:2.0:User"], "id": "2819c223-7f76-453a-919d-413861904646", - "externalId": ["701984"], + "externalId": "701984", "userName": "bjensen@example.com", "name": { "formatted": "Ms. Barbara J Jensen III", "familyName": "Jensen", "givenName": "Barbara", "middleName": "Jane", "honorificPrefix": "Ms.", "honorificSuffix": "III" }, "displayName": "Babs Jensen", @@ -1352,21 +1361,21 @@ 8.3. Enterprise User Extension Representation The following is a non-normative example of the fully populated User using the enterprise User extension in JSON format. { "schemas": [ "urn:ietf:params:scim:schemas:core:2.0:User", "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User"], "id": "2819c223-7f76-453a-919d-413861904646", - "externalId": ["701984"], + "externalId": "701984", "userName": "bjensen@example.com", "name": { "formatted": "Ms. Barbara J Jensen III", "familyName": "Jensen", "givenName": "Barbara", "middleName": "Jane", "honorificPrefix": "Ms.", "honorificSuffix": "III" }, "displayName": "Babs Jensen", @@ -3044,20 +3051,23 @@ [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005. [RFC4647] Phillips, A. and M. Davis, "Matching of Language Tags", BCP 47, RFC 4647, September 2006. [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008. + [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, + October 2008. + [RFC5646] Phillips, A. and M. Davis, "Tags for Identifying Languages", BCP 47, RFC 5646, September 2009. [RFC6557] Lear, E. and P. Eggert, "Procedures for Maintaining the Time Zone Database", BCP 175, RFC 6557, February 2012. [RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 7159, March 2014. [RFC7231] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol @@ -3238,20 +3249,23 @@ Corrected JSON examples to be 72 characters or less per line Corrected enterprise User manager attribute to use sub-attribute value and make multi-valued Corrected sec 8.7, make members multi-valued in JSON Added missing definition for subattributes in sec 7, Schema Definition + Draft 13 - PH - Correctings NITS to externalId example and clarified + phoneNumber & emails canonicalization + Authors' Addresses Phil Hunt (editor) Oracle Corporation Email: phil.hunt@yahoo.com Kelly Grizzle SailPoint