<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html lang="en"><head><title>Draft: OpenID Connect Profile for SCIM Services</title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="description" content="OpenID Connect Profile for SCIM Services">
<meta name="generator" content="xml2rfc v1.37pre1 (http://xml.resource.org/)">
<style type='text/css'><!--
body {
font-family: verdana, charcoal, helvetica, arial, sans-serif;
font-size: small; color: #000; background-color: #FFF;
margin: 2em;
}
h1, h2, h3, h4, h5, h6 {
font-family: helvetica, monaco, "MS Sans Serif", arial, sans-serif;
font-weight: bold; font-style: normal;
}
h1 { color: #900; background-color: transparent; text-align: right; }
h3 { color: #333; background-color: transparent; }
td.RFCbug {
font-size: x-small; text-decoration: none;
width: 30px; height: 30px; padding-top: 2px;
text-align: justify; vertical-align: middle;
background-color: #000;
}
td.RFCbug span.RFC {
font-family: monaco, charcoal, geneva, "MS Sans Serif", helvetica, verdana, sans-serif;
font-weight: bold; color: #666;
}
td.RFCbug span.hotText {
font-family: charcoal, monaco, geneva, "MS Sans Serif", helvetica, verdana, sans-serif;
font-weight: normal; text-align: center; color: #FFF;
}
table.TOCbug { width: 30px; height: 15px; }
td.TOCbug {
text-align: center; width: 30px; height: 15px;
color: #FFF; background-color: #900;
}
td.TOCbug a {
font-family: monaco, charcoal, geneva, "MS Sans Serif", helvetica, sans-serif;
font-weight: bold; font-size: x-small; text-decoration: none;
color: #FFF; background-color: transparent;
}
td.header {
font-family: arial, helvetica, sans-serif; font-size: x-small;
vertical-align: top; width: 33%;
color: #FFF; background-color: #666;
}
td.author { font-weight: bold; font-size: x-small; margin-left: 4em; }
td.author-text { font-size: x-small; }
/* info code from SantaKlauss at http://www.madaboutstyle.com/tooltip2.html */
a.info {
/* This is the key. */
position: relative;
z-index: 24;
text-decoration: none;
}
a.info:hover {
z-index: 25;
color: #FFF; background-color: #900;
}
a.info span { display: none; }
a.info:hover span.info {
/* The span will display just on :hover state. */
display: block;
position: absolute;
font-size: smaller;
top: 2em; left: -5em; width: 15em;
padding: 2px; border: 1px solid #333;
color: #900; background-color: #EEE;
text-align: left;
}
a { font-weight: bold; }
a:link { color: #900; background-color: transparent; }
a:visited { color: #633; background-color: transparent; }
a:active { color: #633; background-color: transparent; }
p { margin-left: 2em; margin-right: 2em; }
p.copyright { font-size: x-small; }
p.toc { font-size: small; font-weight: bold; margin-left: 3em; }
table.toc { margin: 0 0 0 3em; padding: 0; border: 0; vertical-align: text-top; }
td.toc { font-size: small; font-weight: bold; vertical-align: text-top; }
ol.text { margin-left: 2em; margin-right: 2em; }
ul.text { margin-left: 2em; margin-right: 2em; }
li { margin-left: 3em; }
/* RFC-2629 <spanx>s and <artwork>s. */
em { font-style: italic; }
strong { font-weight: bold; }
dfn { font-weight: bold; font-style: normal; }
cite { font-weight: normal; font-style: normal; }
tt { color: #036; }
tt, pre, pre dfn, pre em, pre cite, pre span {
font-family: "Courier New", Courier, monospace; font-size: small;
}
pre {
text-align: left; padding: 4px;
color: #000; background-color: #CCC;
}
pre dfn { color: #900; }
pre em { color: #66F; background-color: #FFC; font-weight: normal; }
pre .key { color: #33C; font-weight: bold; }
pre .id { color: #900; }
pre .str { color: #000; background-color: #CFF; }
pre .val { color: #066; }
pre .rep { color: #909; }
pre .oth { color: #000; background-color: #FCF; }
pre .err { background-color: #FCC; }
/* RFC-2629 <texttable>s. */
table.all, table.full, table.headers, table.none {
font-size: small; text-align: center; border-width: 2px;
vertical-align: top; border-collapse: collapse;
}
table.all, table.full { border-style: solid; border-color: black; }
table.headers, table.none { border-style: none; }
th {
font-weight: bold; border-color: black;
border-width: 2px 2px 3px 2px;
}
table.all th, table.full th { border-style: solid; }
table.headers th { border-style: none none solid none; }
table.none th { border-style: none; }
table.all td {
border-style: solid; border-color: #333;
border-width: 1px 2px;
}
table.full td, table.headers td, table.none td { border-style: none; }
hr { height: 1px; }
hr.insert {
width: 80%; border-style: none; border-width: 0;
color: #CCC; background-color: #CCC;
}
--></style>
</head>
<body>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<table summary="layout" width="66%" border="0" cellpadding="0" cellspacing="0"><tr><td><table summary="layout" width="100%" border="0" cellpadding="2" cellspacing="1">
<tr><td class="header">Draft</td><td class="header">P. Hunt</td></tr>
<tr><td class="header"> </td><td class="header">Oracle</td></tr>
<tr><td class="header"> </td><td class="header">C. Mortimore</td></tr>
<tr><td class="header"> </td><td class="header">Salesforce</td></tr>
<tr><td class="header"> </td><td class="header">June 15, 2016</td></tr>
</table></td></tr></table>
<h1><br />OpenID Connect Profile for SCIM Services</h1>
<h3>Abstract</h3>
<p>SCIM (RFC7644) is an IETF protocol that enables HTTP clients to retrieve
and manage cross-domain identities. OpenID Connect 1.0 is a simple identity
layer on top of the OAuth 2.0 protocol which offers access to profile
information through a UserInfo endpoint. This specification defines
how OpenID Connect relying parties may discover availability of and register for,
and access, SCIM services as part of an OpenID Provider (OP) services.
</p><a name="toc"></a><br /><hr />
<h3>Table of Contents</h3>
<p class="toc">
<a href="#Introduction">1.</a>
Introduction<br />
<a href="#rnc">1.1.</a>
Requirements Notation and Conventions<br />
<a href="#Terminology">1.2.</a>
Terminology<br />
<a href="#metadata">2.</a>
Metadata and Claim Defintions<br />
<a href="#discoveryMetadata">2.1.</a>
Discovery Metadata<br />
<a href="#registrationMetadata">2.2.</a>
Dynamic Registration Metadata<br />
<a href="#idTokenClaims">2.3.</a>
ID Token Claims<br />
<a href="#anchor1">3.</a>
Using SCIM<br />
<a href="#Security">4.</a>
Security Considerations<br />
<a href="#Privacy">5.</a>
Privacy Considerations<br />
<a href="#PII">5.1.</a>
Personally Identifiable Information<br />
<a href="#AccessMonitoring">5.2.</a>
Data Access Monitoring<br />
<a href="#Correlation">5.3.</a>
Correlation<br />
<a href="#OfflineAccessPrivacy">5.4.</a>
Offline Access<br />
<a href="#IANA">6.</a>
IANA Considerations<br />
<a href="#ClaimsRegistry">6.1.</a>
JSON Web Token Claims Registration<br />
<a href="#ClaimsContents">6.1.1.</a>
Registry Contents<br />
<a href="#rfc.references1">7.</a>
Normative References<br />
<a href="#Acknowledgements">Appendix A.</a>
Acknowledgements<br />
<a href="#Notices">Appendix B.</a>
Notices<br />
<a href="#rfc.authors">§</a>
Authors' Addresses<br />
</p>
<br clear="all" />
<a name="Introduction"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.1"></a><h3>1.
Introduction</h3>
<p>SCIM <a class='info' href='#RFC7644'>[RFC7644]<span> (</span><span class='info'>Hunt, P., Ed., Grizzle, K., Ansari, M., Wahlstroem, E., and C. Mortimore, “System for Cross-domain Identity Management: Protocol,” September 2015.</span><span>)</span></a> is an IETF protocol that enables HTTP clients to retrieve
and manage cross-domain identities. OpenID Connect 1.0 is a simple identity
layer on top of the OAuth 2.0 <a class='info' href='#RFC6749'>[RFC6749]<span> (</span><span class='info'>Hardt, D., Ed., “The OAuth 2.0 Authorization Framework,” October 2012.</span><span>)</span></a> protocol which offers access to profile
information through a UserInfo endpoint (see <a class='info' href='#OpenID.Core'>Section 5.3<span> (</span><span class='info'>Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and C. Mortimore, “OpenID Connect Core 1.0,” November 2014.</span><span>)</span></a> [OpenID.Core]). This specification defines
how OpenID Connect relying parties may discover availability of and register for,
and access, SCIM services as part of an OpenID Provider services.
</p>
<p>This specification defines the following metadata:</p>
<ul class="text">
<li>Discovery metadata indicating the avilability of a SCIM protocol base endpoint.
</li>
<li>Dynamic registration metadata that is used to indicate a clients intent to use the SCIM protocol and its associated endpoint.
</li>
<li>An additional ID Token claim which specifies the SCIM resource endpoint and identifier associated with the authenticate subject.
</li>
</ul><p>
In addition to the above metadata attributes and claims, the specification will also show how a client MAY access the SCIM endpoint.
</p>
<a name="rnc"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.1.1"></a><h3>1.1.
Requirements Notation and Conventions</h3>
<p>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <a class='info' href='#RFC2119'>RFC 2119<span> (</span><span class='info'>Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.</span><span>)</span></a> [RFC2119].
</p>
<p>
In the .txt version of this document,
values are quoted to indicate that they are to be taken literally.
When using these values in protocol messages,
the quotes MUST NOT be used as part of the value.
In the HTML version of this document,
values to be taken literally are indicated by
the use of <tt>this fixed-width font</tt>.
</p>
<a name="Terminology"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.1.2"></a><h3>1.2.
Terminology</h3>
<p>
This specification uses the terms "Access Token", "Authorization Code",
"Authorization Endpoint", "Authorization Grant", "Authorization Server",
"Client", "Client Authentication", "Client Identifier", "Client Secret",
"Grant Type", "Protected Resource", "Redirection URI", "Refresh Token",
"Resource Owner", "Resource Server", "Response Type", and "Token Endpoint"
defined by <a class='info' href='#RFC6749'>OAuth 2.0<span> (</span><span class='info'>Hardt, D., Ed., “The OAuth 2.0 Authorization Framework,” October 2012.</span><span>)</span></a> [RFC6749],
the terms "JSON Web Token (JWT)" and "Nested JWT"
defined by <a class='info' href='#RFC7519'>JSON Web Token (JWT)<span> (</span><span class='info'>Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token (JWT),” May 2015.</span><span>)</span></a> [RFC7519],
<a class='info' href='#RFC7644'>SCIM Protocol<span> (</span><span class='info'>Hunt, P., Ed., Grizzle, K., Ansari, M., Wahlstroem, E., and C. Mortimore, “System for Cross-domain Identity Management: Protocol,” September 2015.</span><span>)</span></a> [RFC7644],
<a class='info' href='#OpenID.Core'>OpenID Connect Core 1.0<span> (</span><span class='info'>Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and C. Mortimore, “OpenID Connect Core 1.0,” November 2014.</span><span>)</span></a> [OpenID.Core]. <a class='info' href='#OpenID.Discovery'>OpenID Discovery 1.0<span> (</span><span class='info'>Sakimura, N., Bradley, J., Jones, M., and E. Jay, “OpenID Connect Discovery 1.0,” November 2014.</span><span>)</span></a> [OpenID.Discovery],
and the terms defined by
<a class='info' href='#OpenID.Registration'>OpenID Connect Dynamic Client Registration 1.0<span> (</span><span class='info'>Sakimura, N., Bradley, J., and M. Jones, “OpenID Connect Dynamic Client Registration 1.0,” November 2014.</span><span>)</span></a> [OpenID.Registration].
</p>
<p>This specification uses the OpenID term "relying party" to refer to
what is defined as a "client" in SCIM protocol (see <a class='info' href='#RFC7643'>Section 1.2<span> (</span><span class='info'>Hunt, P., Ed., Grizzle, K., Wahlstroem, E., and C. Mortimore, “System for Cross-domain Identity Management: Core Schema,” September 2015.</span><span>)</span></a> [RFC7643]).
</p>
<a name="metadata"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.2"></a><h3>2.
Metadata and Claim Defintions</h3>
<a name="discoveryMetadata"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.2.1"></a><h3>2.1.
Discovery Metadata</h3>
<p>This specification extends the OpenID Connect Discovery metadata
<a class='info' href='#OpenID.Discovery'>Section 3<span> (</span><span class='info'>Sakimura, N., Bradley, J., Jones, M., and E. Jay, “OpenID Connect Discovery 1.0,” November 2014.</span><span>)</span></a> [OpenID.Discovery] and defines the following:</p>
<blockquote class="text"><dl>
<dt>scim_endpoint</dt>
<dd>RECOMMENDED. The base URI of the OP's
designated SCIM service provider. The base URI is as defined in
<a class='info' href='#RFC7644'>Section 1.3<span> (</span><span class='info'>Hunt, P., Ed., Grizzle, K., Ansari, M., Wahlstroem, E., and C. Mortimore, “System for Cross-domain Identity Management: Protocol,” September 2015.</span><span>)</span></a> [RFC7644]. This URI when appended
with a path of <tt>/Me</tt> points to the subject
authenticated by the OP. Further, SCIM clients MAY discover SCIM
configuration metadata by using this URI to query endpoints such
as <tt>/ServiceProviderConfig</tt> (see <a class='info' href='#RFC7644'>Section 3.2<span> (</span><span class='info'>Hunt, P., Ed., Grizzle, K., Ansari, M., Wahlstroem, E., and C. Mortimore, “System for Cross-domain Identity Management: Protocol,” September 2015.</span><span>)</span></a> [RFC7644]).
</dd>
</dl></blockquote><p>
</p>
<a name="registrationMetadata"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.2.2"></a><h3>2.2.
Dynamic Registration Metadata</h3>
<p>This specification extends the OpenID Connect Dynamic Registration
draft (see <a class='info' href='#OpenID.Registration'>Section 2<span> (</span><span class='info'>Sakimura, N., Bradley, J., and M. Jones, “OpenID Connect Dynamic Client Registration 1.0,” November 2014.</span><span>)</span></a> [OpenID.Registration]),
and defines the following metadata:</p>
<blockquote class="text"><dl>
<dt>scim_profile</dt>
<dd>RECOMMENDED. Boolean value. When
the value is "true", it indicates that the client will use SCIM Protocol
<a class='info' href='#RFC7644'>[RFC7644]<span> (</span><span class='info'>Hunt, P., Ed., Grizzle, K., Ansari, M., Wahlstroem, E., and C. Mortimore, “System for Cross-domain Identity Management: Protocol,” September 2015.</span><span>)</span></a> to accessuser information.
</dd>
</dl></blockquote>
<a name="idTokenClaims"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.2.3"></a><h3>2.3.
ID Token Claims</h3>
<p>This specification extends the claims in OpenID Connect Core
<a class='info' href='#OpenID.Core'>Section 5<span> (</span><span class='info'>Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and C. Mortimore, “OpenID Connect Core 1.0,” November 2014.</span><span>)</span></a> [OpenID.Core] and defines the following:</p>
<blockquote class="text"><dl>
<dt>scim_id</dt>
<dd>An identifier whose value corresponds
to the <tt>id</tt> attribute as defined in <a class='info' href='#RFC7643'>Section 3.1<span> (</span><span class='info'>Hunt, P., Ed., Grizzle, K., Wahlstroem, E., and C. Mortimore, “System for Cross-domain Identity Management: Core Schema,” September 2015.</span><span>)</span></a> [RFC7643]
that is associated with the authenticated subject (<tt>sub</tt>).
</dd>
<dt>scim_location</dt>
<dd>An URI whose value corresponds
to the <tt>meta.location</tt> attribute as defined in <a class='info' href='#RFC7643'>Section 3.1<span> (</span><span class='info'>Hunt, P., Ed., Grizzle, K., Wahlstroem, E., and C. Mortimore, “System for Cross-domain Identity Management: Core Schema,” September 2015.</span><span>)</span></a> [RFC7643]
and that is associated with the authenticated subject (<tt>sub</tt>).
If this value differs from the discovered <tt>scim_endpoint</tt>,
the client MUST use the ID Token claim <tt>scim_location</tt> value.
</dd>
</dl></blockquote>
<a name="anchor1"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.3"></a><h3>3.
Using SCIM</h3>
<p>When using SCIM, the relying party MAY use all the protocol features
of SCIM and act as a SCIM client. A relying party MAY
query SCIM configuration endpoints such as:</p>
<blockquote class="text">
<p><em>/ServiceProviderConfig</em>
</p>
<p><em>/ResourceTypes</em>
</p>
<p><em>/Schemas</em>
</p>
</blockquote>
<p>The OpenID Connect profile for SCIM provides two ways for a
relying party to construct a SCIM URI for the authenticated subject:
</p>
<ul class="text">
<li>The relying party MAY use the previously discovered
<tt>scim_endpoint</tt> plus the path
<tt>/Me</tt> as a URI alias (see Section
3.11 of <a class='info' href='#RFC7644'>[RFC7644]<span> (</span><span class='info'>Hunt, P., Ed., Grizzle, K., Ansari, M., Wahlstroem, E., and C. Mortimore, “System for Cross-domain Identity Management: Protocol,” September 2015.</span><span>)</span></a>). Or,
</li>
<li>The relying party MAY use the URI returned in the <tt>scim_resource</tt>
ID_Token claim provided.
</li>
</ul>
<p>
When accessing the SCIM endpoint, the relying party SHOULD use the
access token issued in the response from the OP as its authorization
to access the SCIM endpoint as per section 2 of
<a class='info' href='#RFC6750'>OAuth 2.0 Bearer Token Usage<span> (</span><span class='info'>Jones, M. and D. Hardt, “The OAuth 2.0 Authorization Framework: Bearer Token Usage,” October 2012.</span><span>)</span></a> [RFC6750].
</p>
<p>OpenID Connect relying parties MAY use <tt>scope</tt>
values to request authorization as per Section 5.4 <a class='info' href='#OpenID.Core'>[OpenID.Core]<span> (</span><span class='info'>Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and C. Mortimore, “OpenID Connect Core 1.0,” November 2014.</span><span>)</span></a>.
The values used in OpenID Connect SHALL be ignored for the purpose
of authorizing access to SCIM. These include:</p>
<ul class="text">
<li>openid
</li>
<li>profile
</li>
<li>email
</li>
<li>address
</li>
<li>phone
</li>
</ul><p>These scopes SHALL continue to be used as defined by OpenID
Connect Core. For example, as a list of claims to be included in the ID_Token.
</p>
<p>OpenID Connect Providers offering SCIM profile services MAY support
SCIM specific scopes not defined in this specification. OpenID Connect
Providers MAY also use registration data to determine the appropriate
scope of authorization for the purpose of access to the SCIM endpoint.
</p>
<a name="Security"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.4"></a><h3>4.
Security Considerations</h3>
<p>
This specification references the security considerations defined in
Section 10 of <a class='info' href='#RFC6749'>OAuth 2.0<span> (</span><span class='info'>Hardt, D., Ed., “The OAuth 2.0 Authorization Framework,” October 2012.</span><span>)</span></a> [RFC6749], and
Section 5 of <a class='info' href='#RFC6750'>OAuth 2.0 Bearer Token Usage<span> (</span><span class='info'>Jones, M. and D. Hardt, “The OAuth 2.0 Authorization Framework: Bearer Token Usage,” October 2012.</span><span>)</span></a> [RFC6750].
Furthermore, the <a class='info' href='#RFC6819'>OAuth 2.0 Threat Model and Security
Considerations<span> (</span><span class='info'>Lodderstedt, T., Ed., McGloin, M., and P. Hunt, “OAuth 2.0 Threat Model and Security Considerations,” January 2013.</span><span>)</span></a> [RFC6819] specification provides an extensive list of threats and controls
that apply to this specification as well,
given that it is based upon OAuth 2.0.
<a class='info' href='#ISO29115'>ISO/IEC 29115<span> (</span><span class='info'>International Organization for Standardization, “ISO/IEC 29115:2013 -- Information technology - Security techniques - Entity authentication assurance framework,” March 2013.</span><span>)</span></a> [ISO29115]
also provides threats and controls that
implementers need to take into account.
Implementers are highly advised to
read these references in detail and apply the countermeasures described therein.
</p>
<a name="Privacy"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.5"></a><h3>5.
Privacy Considerations</h3>
<a name="PII"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.5.1"></a><h3>5.1.
Personally Identifiable Information</h3>
<p>The SCIM service providers typically contain Personally Identifiable
Information (PII). As such, End-User consent for the release of the information
for the specified purpose should be obtained at or prior to the
authorization time in accordance with relevant regulations. The purpose
of use is typically registered in association with the <tt>redirect_uris</tt>.
</p>
<p>Only necessary UserInfo data should be stored at the Client and the
Client SHOULD associate the received data with the purpose of use
statement.
</p>
<a name="AccessMonitoring"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.5.2"></a><h3>5.2.
Data Access Monitoring</h3>
<p>
The SCIM Resource Server SHOULD make End-Users' resource access logs
available to them so that they can monitor who accessed their data.
</p>
<a name="Correlation"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.5.3"></a><h3>5.3.
Correlation</h3>
<p>To protect the End-User from a possible correlation among Clients, the
use of a Pairwise Pseudonymous Identifier (PPID) as the
<tt>sub</tt> (subject) SHOULD be considered.
</p>
<a name="OfflineAccessPrivacy"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.5.4"></a><h3>5.4.
Offline Access</h3>
<p>
Offline access enables access to Claims when the user is not present,
posing greater privacy risk than the Claims transfer when the user is present.
Therefore, it is prudent to obtain explicit consent for
offline access to resources.
This specification mandates the use of the <tt>prompt</tt>
parameter to obtain consent unless it is already known that the
request complies with the conditions for processing the request in each jurisdiction.
</p>
<p>
When an Access Token is returned via the User Agent
using the Implicit Flow or Hybrid Flow, there is
a greater risk of it being exposed to an attacker, who could
later use it to access the UserInfo endpoint.
If the Access Token does not enable offline access and the server
can differentiate whether the Client request has been made
offline or online, the risk will be substantially reduced.
Therefore, this specification mandates ignoring
the offline access request when the Access Token is
transmitted through the User Agent.
Note that differentiating between online and offline access
from the server can be difficult especially for native clients.
The server may well have to rely on heuristics.
Also, the risk of exposure for the Access Token delivered
through the User Agent for the Response Types of
<tt>code token</tt> and
<tt>token</tt> is the same.
Thus, the implementations should be prepared to detect
whether the Access Token was issued through the User Agent
or directly from the Token Endpoint and deny offline access
if the token was issued through the User Agent.
</p>
<p>
Note that although these provisions require an explicit
consent dialogue through the <tt>prompt</tt> parameter,
the mere fact that the user pressed an "accept" button etc.,
might not constitute a valid consent.
Developers should be aware that for the act of consent to
be valid, typically, the impact of the terms have to be
understood by the End-User, the consent must be freely given
and not forced (i.e., other options have to be available),
and the terms must fair and equitable.
In general, it is advisable for the service to follow the
required privacy principles in each jurisdiction and rely on
other conditions for processing the request than simply explicit consent,
as online self-service "explicit consent" often does not
form a valid consent in some jurisdictions.
</p>
<a name="IANA"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.6"></a><h3>6.
IANA Considerations</h3>
<a name="ClaimsRegistry"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.6.1"></a><h3>6.1.
JSON Web Token Claims Registration</h3>
<p>
This specification registers the Claims defined in
<a class='info' href='#idTokenClaims'>Section 2.3<span> (</span><span class='info'>ID Token Claims</span><span>)</span></a> in the IANA JSON Web Token Claims registry
defined in <a class='info' href='#RFC7519'>[RFC7519]<span> (</span><span class='info'>Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token (JWT),” May 2015.</span><span>)</span></a>.
</p>
<a name="ClaimsContents"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.6.1.1"></a><h3>6.1.1.
Registry Contents</h3>
<p>
</p>
<ul class="text">
<li>
Claim Name: <tt>scim_id</tt>
</li>
<li>
Claim Description: SCIM Identifier
</li>
<li>
Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
</li>
<li>
Specification Document(s): <a class='info' href='#idTokenClaims'>Section 2.3<span> (</span><span class='info'>ID Token Claims</span><span>)</span></a> of this document
</li>
</ul><p>
</p>
<p>
</p>
<ul class="text">
<li>
Claim Name: <tt>scim_location</tt>
</li>
<li>
Claim Description: SCIM Resource Location
</li>
<li>
Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
</li>
<li>
Specification Document(s): <a class='info' href='#idTokenClaims'>Section 2.3<span> (</span><span class='info'>ID Token Claims</span><span>)</span></a> of this document
</li>
</ul><p>
</p>
<a name="rfc.references1"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<h3>7. Normative References</h3>
<table width="99%" border="0">
<tr><td class="author-text" valign="top"><a name="ISO29115">[ISO29115]</a></td>
<td class="author-text">International Organization for Standardization, “<a href="http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=45138">ISO/IEC 29115:2013 --
Information technology - Security techniques - Entity authentication
assurance framework</a>,” ISO/IEC 29115, March 2013.</td></tr>
<tr><td class="author-text" valign="top"><a name="OpenID.Core">[OpenID.Core]</a></td>
<td class="author-text">Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and C. Mortimore, “<a href="http://openid.net/specs/openid-connect-core-1_0.html">OpenID Connect Core 1.0</a>,” November 2014.</td></tr>
<tr><td class="author-text" valign="top"><a name="OpenID.Discovery">[OpenID.Discovery]</a></td>
<td class="author-text">Sakimura, N., Bradley, J., Jones, M., and E. Jay, “<a href="http://openid.net/specs/openid-connect-discovery-1_0.html">OpenID Connect Discovery 1.0</a>,” November 2014.</td></tr>
<tr><td class="author-text" valign="top"><a name="OpenID.Registration">[OpenID.Registration]</a></td>
<td class="author-text">Sakimura, N., Bradley, J., and M. Jones, “<a href="http://openid.net/specs/openid-connect-registration-1_0.html">OpenID Connect Dynamic Client Registration 1.0</a>,” November 2014.</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC2119">[RFC2119]</a></td>
<td class="author-text">Bradner, S., “<a href="http://www.rfc-editor.org/info/rfc2119">Key words for use in RFCs to Indicate Requirement Levels</a>,” BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC2616">[RFC2616]</a></td>
<td class="author-text">Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “<a href="http://www.rfc-editor.org/info/rfc2616">Hypertext Transfer Protocol -- HTTP/1.1</a>,” RFC 2616, DOI 10.17487/RFC2616, June 1999.</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC3986">[RFC3986]</a></td>
<td class="author-text">Berners-Lee, T., Fielding, R., and L. Masinter, “<a href="http://www.rfc-editor.org/info/rfc3986">Uniform Resource Identifier (URI): Generic Syntax</a>,” STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005.</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC5246">[RFC5246]</a></td>
<td class="author-text">Dierks, T. and E. Rescorla, “<a href="http://www.rfc-editor.org/info/rfc5246">The Transport Layer Security (TLS) Protocol Version 1.2</a>,” RFC 5246, DOI 10.17487/RFC5246, August 2008.</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC6125">[RFC6125]</a></td>
<td class="author-text">Saint-Andre, P. and J. Hodges, “<a href="http://www.rfc-editor.org/info/rfc6125">Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)</a>,” RFC 6125, DOI 10.17487/RFC6125, March 2011.</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC6749">[RFC6749]</a></td>
<td class="author-text">Hardt, D., Ed., “<a href="http://www.rfc-editor.org/info/rfc6749">The OAuth 2.0 Authorization Framework</a>,” RFC 6749, DOI 10.17487/RFC6749, October 2012.</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC6750">[RFC6750]</a></td>
<td class="author-text">Jones, M. and D. Hardt, “<a href="http://www.rfc-editor.org/info/rfc6750">The OAuth 2.0 Authorization Framework: Bearer Token Usage</a>,” RFC 6750, DOI 10.17487/RFC6750, October 2012.</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC6819">[RFC6819]</a></td>
<td class="author-text">Lodderstedt, T., Ed., McGloin, M., and P. Hunt, “<a href="http://www.rfc-editor.org/info/rfc6819">OAuth 2.0 Threat Model and Security Considerations</a>,” RFC 6819, DOI 10.17487/RFC6819, January 2013.</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC7519">[RFC7519]</a></td>
<td class="author-text">Jones, M., Bradley, J., and N. Sakimura, “<a href="http://www.rfc-editor.org/info/rfc7519">JSON Web Token (JWT)</a>,” RFC 7519, DOI 10.17487/RFC7519, May 2015.</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC7643">[RFC7643]</a></td>
<td class="author-text">Hunt, P., Ed., Grizzle, K., Wahlstroem, E., and C. Mortimore, “<a href="http://www.rfc-editor.org/info/rfc7643">System for Cross-domain Identity Management: Core Schema</a>,” RFC 7643, DOI 10.17487/RFC7643, September 2015.</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC7644">[RFC7644]</a></td>
<td class="author-text">Hunt, P., Ed., Grizzle, K., Ansari, M., Wahlstroem, E., and C. Mortimore, “<a href="http://www.rfc-editor.org/info/rfc7644">System for Cross-domain Identity Management: Protocol</a>,” RFC 7644, DOI 10.17487/RFC7644, September 2015.</td></tr>
</table>
<a name="Acknowledgements"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.A"></a><h3>Appendix A.
Acknowledgements</h3>
<a name="Notices"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.B"></a><h3>Appendix B.
Notices</h3>
<p>Copyright (c) 2016 The OpenID Foundation.
</p>
<p>
The OpenID Foundation (OIDF) grants to any Contributor, developer,
implementer, or other interested party a non-exclusive, royalty free,
worldwide copyright license to reproduce, prepare derivative works from,
distribute, perform and display, this Implementers Draft or
Final Specification solely for the purposes of (i) developing
specifications, and (ii) implementing Implementers Drafts and
Final Specifications based on such documents, provided that attribution
be made to the OIDF as the source of the material, but that such attribution
does not indicate an endorsement by the OIDF.
</p>
<p>
The technology described in this specification was
made available from contributions from various sources,
including members of the OpenID Foundation and others.
Although the OpenID Foundation has taken steps to help ensure
that the technology is available for distribution, it takes
no position regarding the validity or scope of any intellectual
property or other rights that might be claimed to pertain to
the implementation or use of the technology described in
this specification or the extent to which any license under
such rights might or might not be available; neither does it
represent that it has made any independent effort to identify
any such rights. The OpenID Foundation and the contributors
to this specification make no (and hereby expressly disclaim any)
warranties (express, implied, or otherwise), including implied
warranties of merchantability, non-infringement, fitness for
a particular purpose, or title, related to this specification,
and the entire risk as to implementing this specification is
assumed by the implementer. The OpenID Intellectual
Property Rights policy requires contributors to offer
a patent promise not to assert certain patent claims against
other contributors and against implementers. The OpenID Foundation invites
any interested party to bring to its attention any copyrights,
patents, patent applications, or other proprietary rights
that may cover technology that may be required to practice
this specification.
</p>
<a name="rfc.authors"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<h3>Authors' Addresses</h3>
<table width="99%" border="0" cellpadding="0" cellspacing="0">
<tr><td class="author-text"> </td>
<td class="author-text">Phil Hunt</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Oracle Corporation</td></tr>
<tr><td class="author" align="right">Email: </td>
<td class="author-text"><a href="mailto:phil.hunt@oracle.com">phil.hunt@oracle.com</a></td></tr>
<tr><td class="author" align="right">URI: </td>
<td class="author-text"><a href="http://twitter.com/independentid">http://twitter.com/independentid</a></td></tr>
<tr cellpadding="3"><td> </td><td> </td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Chuck Mortimore</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Salesforce</td></tr>
<tr><td class="author" align="right">Email: </td>
<td class="author-text"><a href="mailto:cmortimore@salesforce.com">cmortimore@salesforce.com</a></td></tr>
<tr><td class="author" align="right">URI: </td>
<td class="author-text"><a href="https://twitter.com/cmort">https://twitter.com/cmort</a></td></tr>
</table>
</body></html>