In this article, I will try to clarify it from two approaches: etymology and legal literature.

1. Etymology of “privacy”

According to Online Etymology Dictionary,  privacy is a word first appeared in the 15th century and is composed of private + -cy, which is an abstract noun suffix of quality or rank.

“Private” is a word that appeared in the late 14th century that came from Latin “privatus”,  ”set apart, belonging to oneself” (not to the state), used in contrast to publicus, communis; originally pp. stem of privare ”to separate, deprive,” from privus”one’s own, individual. In short, it points to something that you have sovereign over. Thus, the notion of the “right of privacy” as “self-control right” is not too far away from its original meaning.

2. Right to Privacy in legal literature^[1]

On the other hand, in the legal literature, right to privacy is often referred to as “right to be let alone.” This comes from the Warren and Brandeis’s famous paper “Right to Privacy”[2] that quotes Justice Cooley’s “Law of Torts”[3]. The phrase however is often mistaken to be pointing to the right to the solitude, which I think is not the case. Let me quote from Justis Cooley’s paper.

 Personal immunity. The right to one’s person may be said to be a right of complete immunity: to be let alone. The corresponding duty is, not to inflict an injury, and not, within such proximity as might render it successful, to attempt the infliction of an injury. In this particular the duty goes beyond what is required in most cases; for usually an unexecuted purpose or an unsuccessful attempt is not noticed. But the attempt to commit a battery involves many elements of injury not always present in breaches of duty; it involves usually an insult, a putting in fear, a sudden call upon the energies for prompt and effectual resistance. There is very likely a shock to the nerves, and the peace and quiet of the individual is disturbed for a period of greater or less duration. There is consequently abundant reason in support of the rule of law which makes the assault a legal wrong, even though no battery takes place. Indeed, in this case the law goes still further and makes the attempted blow a criminal offense also. [4]

So, “right to be let alone” is synonymous to the “personal immunity”. If you read what follows, you will see that “person” includes not only the physical body but also the soul. In other words, “Right to be let alone” is “the immunity of one’s body and  soul” and is very far from the impression that non-legal folks gets from the phrase “right to be let alone.”

Warren and Brandeis follows this and they define the right to privacy as a very basic human right of sovereignty over one’s private property, both tangible and intangible, under the common law, that such rights to free speech, copyright, etc. are derivative right on the privacy[5]. The consumer privacy bill of right that the Obama legislation put forward in 2012 [6]  follows this as well. Indeed, we can almost interpret right to privacy as the right to personal freedom also known as  liberty.

Warren and Brandeis then goes on to discuss the difference between the right to privacy and the right to property, copyright,  slander and of libel, and discusses why being intentional is not necessary in its infringement, and under what condition such right is limited [7]. It is a short paper that I highly recommend you to read. The online version can be found at the MIT site.

3. Right to privacy in a narrower sense and confusion arising from it

Thus, both direction derived the same result. Right to privacy is the sovereign right to over one’s private tangible and intangible property including one’s body and soul. In another word, it is a basic human right of personal freedom (liberty).

Note however, much of it actually can be protected by more specific laws, and where there is a defined law, it should be dealt with it. The remainder after all those area covered by specific laws seems to be often referred to as the right to privacy in narrow sense. This is a  negative way of defining it. Trying to do it in a positive statement is utterly impossible. This is one of the reason why it is so hard to define the right to privacy in narrower sense. I think “right to control personal image through the control of the use and release of personal information” covers good part of it, but not all. Note that personal data protection is just a tool to protect this right, and not something we should be aiming at. It is the privacy that needs to be protected, not the data per se.

Further, the fact those specific rights deducted differs from a jurisdiction to another. This, I feel, is one of the reason that making it difficult to bring different jurisdiction to the same page.Whereas the free world probably has very similar notion on the personal freedom (liberty), which is depicted as the rectangle in the following figure, the remainder after removing the area covered by specific laws are all different.

Figure 1. Confusion around privacy

In addition, in some jurisdiction like EU, Right to respect for private and family life is defined. This is yet another subset of the right to privacy in the broader sense, but due to the similarity in the wording, it often is referred to as the right to privacy as well adding further confusion.

4. Conclusion

Often, it is said that “privacy cannot be defined.” This is not true. Defining it in the narrow sense using “positive expression” is almost impossible, but it can be defined in the “negative expression.” However, when we get to it in the concrete term, the right to privacy in the narrower sense in concrete differs from jurisdiction to jurisdiction resulting in tension and confusion. It is better to define it in the abstract term, and to make the concrete guidance, extract the subset such as “self-image control right” and put it into a statute though it may overlap with existing laws. In addition, it would probably help to create a logical model of what constitutes a violation / infringement etc. as a clearer guidance. I have started it here, which is a very early work in progress, but I would much appreciate your comments on it as well.

[1] I am not a lawyer, so I feel a little inappropriate and intimidated to refer to these document, but they are too important not to mention and analyse.

[2] Warren and Brandeis, “The Right to Privacy”, Harvard Law Review, Vol. IV December 15, 1890 No. 5

[3] Thomas McIntyre Cooley, “Law of Torts”, Callaghan, 1888

[4] http://www.law.louisville.edu/library/collections/brandeis/node/227 . The underline is by the author.

[5] 「These considerations lead to the conclusion that the protection afforded to thoughts, sentiments, and emotions, expressed through the medium of writing or of the arts, so far as it consists in preventing publication, is merely an instance of the enforcement of the more general right of the individual to be let alone. 」

[6] Consumer Privacy Bill of Rights  (http://1.usa.gov/privrights )

[7] This notion of equality being the identity of the concession of certain quantity of sovereignty over oneself can also be found in the speech of Enjolras in Les Misrables by Victor Hugo as follows:

From a political point of view, there is but a single principle; the sovereignty of man over himself. This sovereignty of myself over myself is called Liberty. Where two or three of these sovereignties are combined, the state begins. But in that association there is no abdication. Each sovereignty concedes a certain quantity of itself, for the purpose of forming the common right. This quantity is the same for all of us. This identity of concession which each makes to all, is called Equality. (from Victor Hugo, “Les Miserables” vol. V, Book First, Chapter V. ) 

1. OpenID Signature Check Failure

In section 4.1, the authors points out that although the RP requests the parameters to be signed with openid.ext1.required, since the request is not signed, the openid.ext1.required can be manipulated and thus the response in the openid.signed would not include all of what was in the openid.ext1.required[2].

This interpretation of openid.ext1.required is wrong.

This parameter is defined in OpenID Attribute Exchange 1.0 as follows:

openid.ax.required

Value: an attribute alias, or a list of aliases corresponding to the URIs defined by “openid.ax.type.<alias>” parameters. Multiple attribute aliases are separated with a comma, “,”.

By requesting attributes using this field, a hint is sent to the OP about the RP’s requirements for offering certain functionality and should be used by the OP to help the user decide what attributes to release. RP’s requirements should not be enforced by the OP.

The RP should offer, out of band of attribute exchange, an alternate method of collecting the attributes it needs, if they weren’t obtained via attribute exchange.

As you can see, it has nothing to do with signing. Thus, the claims that was made by the authors are actually false and Figure 8 marking “protected by openid.sig” is wrong. [3]

This does not mean that there was not a vulnerability at Smartsheet. Indeed there was, but the cause is not this one. The root cause is that the Smartsheet used a mail address as the user identifier to log in the user. This is wrong. OpenID Authentication 2.0 mandates the RP to identify the end-user with openid.claimed_id. This is always signed by the IdP, and this is a un-recyclable identifier unlike an email address. If the Smartsheet was implementing the specification properly, this vulnerability did not arise. Indeed, this is an implementation vulnerability and not a protocol vulnerability.

The authors goes on to say:

       Broader impacts. We further discovered that the problem went far beyond Smartsheet. Google confirmed that the flaw also existed in open source projects OpenID4Java (an SDK that Google authentication had been tested against) and Kay Framework. In OpenID4Java, the function for an RP to verify BRM3 is verify(). The source code showed that it only checked whether the signature covered all the elements in the openid.signed list, so a “verified” BRM3 does not ensure authenticity of the elements that the RP required the IdP to sign.

As I wrote above, the “required” parameter is not indicating parameters to be signed. There is no parameter to request the response parameters to be signed in the OpenID Authentication 2.0. It is up-to the IdP to decide what is to be signed besides mandatory parameters such as claimed_id, identity, etc. Therefore, OpenID4Java implementation is actually correct. Therefore, the authors’ claim “we examined other popular websites Yahoo! Mail, zoho.com, manymoon.com and diigo.com. They were all vulnerable to this attack. ” cannot be verified without other evidences.

2. Data Type Confusion

In section “4.5. OpenID’s Data Type Confusion “, the authors identify a problem of RPs interpreting openid.ext1.value.email as email without respect to the value of openid.ext1.type.email. Of course, this is a non-compliant behavior by the RP. Type of openid.ext1.value.email is determined by the value of openid.ext1.type.email. If openid.ext1.type.email= http://schema.openid.net/contact/street2, then openid.ext1.value.email contains the second line of the street address. It is not email address.

Moreover, it is utterly wrong to identify the user with whatever the value of openid.ext1.value.email is.

The correct behavior is to identify the user using openid.claimed_id. Other parameters MUST NOT be used to identify the user. If RP uses any other parameter to identify the user, then it is a security hole. This is the root of problem. 

3. Problem of not reading the specification and the importance of the deployment testing

There is one thing that paper revealed clearly though. People do not read the spec. In this case, both the implementers at Smartsheet etc., nor the authors of this paper read the OpenID Authentication 2.0 and OpenID Attribute Exchange 1.0. It clearly shows how difficult it is to have the implementers read and implement the specs correctly.

Changing the popele’s behavior is one of the hardest thing to achieve, and the formal specification languages is not an easy read. I do not expect the situation to improve much in the coming days.

Then, what can we do to help the situation?

Test tools!

In this respect, for OpenID Connect, test tools has been developed by Andreas Åkre Solberg and Roland Hedberg. Hopefully, the situation will be better for the OpenID Connect. [4]

[1] It is kind of unfortunate that I did not have time to review the paper in detail till now.

[2] In page 6, the authors states: “Particularly, openid.signed contains the list from openid.ext1.required on BRM1, an element that describes which elements the RP requires the IdP to sign, such as email, firstname and lastname, as shown in the popup by the mouse cursor in Figure 8. However, since openid.signed (BRM3) can be controlled by the adversary through openid.ext1.required (BRM1), there is no guarantee that any of the elements that the RP requires the IdP to sign will be signed
by the IdP (i.e., protected by openid.sig) in BRM3. ”

[3] Actually, Figure 8 is very misleading. The authors omits vital information by replacing with [WORD] and [LIST]. In OpenID Attribute Exchange 1.0, the key names like openid.ext1.type.email mean nothing. It may as well mean an address or age or anything. Omitting the value part of the key=value pair makes the figure very misleading.

[4] In fact, the paper is in a way demonstrating the usefulness of the black box deployment testing. I believe this kind of methodology should be widely deployed. I highly value the paper in this respect.

Response from the authors

The authors of the paper kindly provided me an response to the above article shortly after I have posted it.

Here is the response. I would like to take this opportunity to thank them deeply.

Dear Nat,

Thank you for writing the post and forwarding the link to us.

I think we are on the same page about technical natures of the two vulnerability cases. However,  we feel that you misunderstood the purpose of the paper:  we never claimed that the problems we discovered actually are caused by OpenID protocol; we just point out the vulnerabilities in the websites that integrate (sometimes customized) OpenID schemes. Following are the details of our points:

(1)   Again, the paper is about how securely real-world websites deploy SSO schemes. This emphasis is hopefully clear in the title, the abstract and the introduction. We took an end-to-end view about the studied websites, and examined their security as a whole. Given an end-to-end vulnerability, we mainly described the facts, but didn’t take a position about whether it was RP’s fault or IdP’s, or whether it was a protocol bug or an implementation one.

(2)   Specifically about one of your paragraphs in the post:

Please understand that we did not try to interpret openid.ext1.required in the paper, but simply stated a fact: the openid.signed would not include all of what was in the openid.ext1.required.

(3)   Regarding “Figure 8 marking ‘protected by openid.sig’ is wrong,” the paragraph above figure 8 gives the context of this figure. The trace shown in figure 8 was the trace that we actually collected from the website. In such a trace, the indicated elements were indeed protected by openid.sig. Again, we were stating a fact about the specific trace, but didn’t imply that “the openid spec requires such a signature coverage for all traces.”  

(4)   About the “broader impacts” section: similarly, we just stated the fact that “The source code showed that it only checked whether the signature covered all the elements in the openid.signed list, so a “verified” BRM3 does not ensure authenticity of the elements that the RP required the IdP to sign.” We didn’t attempt to say whether it was OpenID4Java’s fault.

(5)   You wrote in the post that “Therefore, the authors’ claim ‘we examined other popular websites Yahoo! Mail,zoho.com, manymoon.com and diigo.com. They were all vulnerable to this attack.’ cannot be verified without other evidences.” Actually these are all RP websites. The sentence we wrote was to state the fact that we checked these websites, and they were vulnerable in the same way. You seem to indicate that we made such a claim based on the fact of OpenID4Java. No, there is no such inference. It is an independent evidence to show that the same vulnerability might be quite common among many websites.

(6)   Regarding your paragraph about the data type confusion case, again, we were describing our observations, and the fact that we found on a number of end-to-end vulnerable websites. We didn’t say whether it was due to the openid spec.

I think that the biggest difference here is that we have different angles about the same set of technical understanding. This paper mainly states concrete facts about how real-world websites deployed SSO schemes, and your angle is mainly about what the specs say and how they should do. We didn’t discuss how they should do until section 5.

Please feel free to let us know how you think.  If you agree with the above comments, we will really appreciate if this can be reflected on your blog. 

Thanks,

Rui

(updated May 1, 2012)

In the first pass, we did it in three steps (1. Registration, 2. Authorization, 3. Userinfo request) , exactly following the Standard model. However, this proved to be a user interface nightmare. In the Standard case, the registration and userinfo request/response happens server to server without a user-agent/browser involvement. Unfortunately, this is not the case for the IdP on iPhone case. All the communication has to be through Safari. Thus, all three steps stated above would involve browser dance, which is a pretty bad user experience.

In the second incarnation, we have decided to overlay the registration and the userinfo request / response over the authorization request / response. We further decided that only request by reference is supported. This has an advantage that the client can be authenticated by the TLS session.

The binding thus became like this:

1. Prepare a request parameter file

Request Object will look like:

{
        "response_type": "token id_token userinfo",
        "client_id": "https://example.com/",
        "scope": "openid profile",
	"userinfo":{
		"claims":{
			"email":null,
			"name":null,
			"picture":null
		}
	},
	"registration":{
		"claims":{
        		"type":"client_association",
        		"contacts":"contact@example.com",
        		"application_name":"Sample RP",
        		"logo_url":"https://example.com/rp/logo.png",
        		"policy_url":"https://example.com/rp/policy.html",
        		"redirect_uris":"httsp://example.com/rp/authz/callback.php"
		}
	}
}

This is then captured into a file with a URL https://example.com/rp/rpf.json

Note that the client_id is not something the IdP gives out to the client, in this case. Instead, it is the fully qualified URL.

2. Make an authorization request

Next step is to make the authorization request.

It is a straight forward “request by reference” except that it uses custome scheme “openid://” instead of normal https://.

Typically, the user arrives at the web site and clicks [Login] button, which is linked to something like:

openid://authz?request_uri=https://example.com/rp/rpf.json&state=a_f2fkEx&nonce=4f8921ce98f89

3. IdP fetches the request file

When the IdP on iPhone is invoked through the custom scheme as in section 2., the IdP obtains the URL of the request file and fetches it.

When doing so, the IdP should check the SSL certificate’s CN to the client_id.

4. User Authorizes

Assuming that the iPhone has a password lock, we can skip the authentication. (If you want, you can set a pin in the IdP application as well.) Thus, the user is shown the authorization dialogue.

5. Response Returned

Once obtained the user authorization, the IdP returns the response in the fragment to the return_uri. The fragment has userinfo token in addition to usual access token and ID token. The page at the return_uri then obtains the fragment, typically by using javascript, and send it back to the client web server for further processing.

In the fragment are three tokens in this case:

• access_token : Normal OAuth 2.0 access token.
• id_token: JWS signed OpenID Connect ID Token. Public key corresponding to the signing key is found in iss & user_id member.
• iss: Issuer of this token. Unlike the normal case where it is a URL, in this self issued IdP, it is the public key of the key pair that was generated for the client.
• user_id: Same as iss. Thus, if iss==user_id, the client can identify that it is a self issued IdP.
• nonce: defined in Messages.
• exp: ditto
• iat: ditto
• …
• userinfo_token: JWT that include the userinfo JSON as the body.

Then the web server inspects id_token, and logs the user in.

6. Advantages and Issues of IdP on a smartphone

There are several advantages that IdP on a smartphone has.

1. Only YOU know where you went: Unlike when using a third party IdP, only you know where you visited.
2. In the phone authentication: An App inside the phone can authenticate against IdP on the phone. No network connection is needed for this.

On the other hand, there are short comings as well.

1. The RP has no way of knowing if the IdP on the smart phone is installed and configured.

If there is a good way to deal with this problem, please let me know.

Indeed, it is actually quite simple to do it. I would use code flow as the base case in this article, because I believe that is the flow people should use for such cases.

Making an OpenID Connect request

In order for the client to make an OpenID Connect request, it needs to have the following information about the server:

• client identifier - An unique identifier issued to the client (RP) to identify itself to the authorization server. (e.g., 3214244 )
• client secret - A shared secret established between the authorization server and client used for signing requests.
• end-user authorization endpoint - The authorization server’s HTTP endpoint capable of authenticating the end-user and obtaining authorization. (e.g., https://server.example.com/authorize )
• token endpoint - The authorization server’s HTTP endpoint capable of issuing access tokens.

In the simplest cases, this information is obtained by the client developer, having read the server’s documentation and pre-registered their application.

Then, for a bear bone authentication request then would put a link like in the HTML page:

<a href="https://server.example.com/authorize?grant_type=code&scope=openid&client_id=3214244&state=af1Ef">
 Login with Example.com
</a>

User initiates the login by clicking on the “Login with Example.com” link, and is taken to the server where he is asked username/password etc. if he is not logged into example.com yet. Once he agrees to login to  the RP, the browser is redirected back to the call back URL at the RP by 302 redirect. A PHP Server side code may look like:

<?php
 header("Location: https://client.example.com/cb?code=8rFowidZfjt&state=af1Ef");
?>

Note: state is the parameter that is used to protect against XSRF in this case. It binds the request to the browser so it cannot be as static as above but that’s a detail so I skip it here.

That’s simple enough is it not?

Calling the Token endpoint to get id_token

Now that the RP has the ‘code’, let’s get the id_token, which is the user login information assertion, from the token endpoint. What do you do? Just GET it with HTTP Basic Auth using client_id, client_secret, and the code you got. So, using PHP and cURL, it would look like:

<?php
 $code = $_GET['code'];
 $ch = curl_init('https://server.example.com/token?code=' . $code);
 curl_setopt($ch, CURLOPT_HEADER, 1);
 curl_setopt($ch, CURLOPT_USERPWD, $client_id . ":" . $client_secret);
 curl_setopt($ch, CURLOPT_RETURNTRANSFER, TRUE);
 $response = curl_exec($ch);
 ?>

The result, $response, would contain a JSON like this (line wraps for display purposes only):

{
 "access_token": "SlAV32hkKG",
 "token_type": "Bearer",
 "refresh_token": "8xLOxBtZp8",
 "expires_in": 3600,
 "id_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.
eyJpc3MiOiJodHRwczovL3NlcnZlci5leGFtcGxlLmNvbSIsInVzZXJfaWQiOiIyNDgy
ODk3NjEwMDEiLCJhdWQiOiJodHRwOi8vY2xpZW50LmV4YW1wbGUuY29tIiwiZXhwIjox
MzExMjgxOTcwfSA.
eDesUD0vzDH3T1G3liaTNOrfaeWYjuRCEPNXVtaazNQ"

}

Never mind what are "access_token", "token_type" etc. What you only care about is the "id_token".

"id_token" is encoded in a format called  JSON Web Token (JWT). JWT is the concatenation of “header”, “body”, “signature” by periods (.). Since you got this through TLS protected channel directly however, you do not need to check the signature for integrity, so you just take out the second portion of it and base64_decode it to get the information out of the id_token. So in PHP you may do like [2]:

<?php
$res = json_decode($response, true);
$id_token = $res['id_token'];
$id_array = mb_split(".", $id_token);
$id_body = base64_decode($id_array[1]); 
?>

The resulting assertion, $id_body in the above example,  about the user (after pretty formatting)  is:

{
 "iss": "https://server.example.com",
 "user_id": "248289761001",
 "aud": "http://client.example.com",
 "exp": 1311281970
}

“iss” is showing the issuer of this token, in this case, the server.example.com. This is a name space of the  user_id, which is unique within the issuer and never reassigned.

When the client stores the user identifier, it MUST store the tuple of the  user_id and iss.

“aud” stands for “audience” and it shows who is the audience of this token. In this case, it is the RP itself. If it is different, you better throw it away.

“exp” is the expiry time of the token. If the current time is after “exp”, e.g., in PHP, if  $exp > time();  the RP should throw it away as well.

So, that is it. Now you know who is the user, i.e., you have authenticated the user.

Is it complex? Nah. It cannot get much simpler than this. It will not take more than ten minutes for the relying party to write a code just to authenticate the user.

Start right away to test your OpenID Connect Provider:

• http://openidtest.uninett.no/

This is an early preview of a pretty complex set of software, so they are asking you to be patient, and report any issues to them. You can do that by posting to our github issue tracker or respond to OpenID AB/Connect WG mailing list.

Here is a video demo of how it all works. It is pretty cool!

OpenID Connect Testing from Andreas Åkre Solberg on Vimeo.

Followings are related links.

• The OpenID Connect Specification
• The OpenID Connect Mailinglist
• Federation Lab OpenID Connect Frontend (Node.js)
• OpenID Connect Backend (Python)

Enjoy!

2012 NSTIC/IDtrust Workshop:   “Technologies and Standards Enabling the Identity Ecosystem”

March 13-14, 2012
NIST – Administration Building – Green Auditorium – Gaithersburg, MD

The response_type parameter, as I understand, indicates what is to be returned from the authorization endpoint.

Thus, if response_type=token, the access token is returned from the authorization endpoint, while if response_type=code, the code is returned. As such, if response_type=code%20token, then both code and access token are to be returned from the authorization endpoint.

Here is a table that describes this relationship in OpenID Connect when scope includes “openid”.

[1] All the AuthZ EP responses are returned in the fragment except for the cases where the response_type included only “code”. See OAuth 2.0 Multiple Response Type Encoding Practices for more details.

It is possible to have response_type=id_token without scope being openid, but in that case, id_token is undefined, and is out of scope of OpenID Connect standard.

So, it is pretty simple. Only the thing to remember is that Authorization Endpoint always returns what was stated in the response_type.

OpenID Conenct Implementer’s Draft voting has finally started. We had a technical problem that delayed the start of the voting almost 23 hours, but as promised, we have started it on the Feb. 7, PST![1] So here it goes!

Voting Page ===> https://openid.net/foundation/members/polls/62

The specifications in questions are:

The specifications are posted at these locations:

• http://openid.net/specs/openid-connect-basic-1_0-15.html
• http://openid.net/specs/openid-connect-discovery-1_0-07.html
• http://openid.net/specs/openid-connect-registration-1_0-08.html
• http://openid.net/specs/openid-connect-messages-1_0-07.html
• http://openid.net/specs/openid-connect-standard-1_0-07.html
• http://openid.net/specs/oauth-v2-multiple-response-types-1_0-03.html

A description of OpenID Connect can be found at http://openid.net/connect/. The working group page is http://openid.net/wg/connect/.

The vote closes on Feb. 15.

OIDF Members, please go to the voting page and vote early!

[1] Thanks Darin Richardson of Refresh Media for sorting this out quickly.

DMARC, which stands for “Domain-based Message Authentication, Reporting & Conformance”, is a technical specification created by a group of organizations that want to help reduce the potential for email-based abuse by solving a couple of long-standing operational, deployment, and reporting issues related to email authentication protocols.

DMARC standardizes how email receivers perform email authentication using the well-known SPF and DKIM mechanisms. This means that senders will experience consistent authentication results for their messages at AOL, Gmail, Hotmail, Yahoo! and any other email receiver implementing DMARC. We hope this will encourage senders to more broadly authenticate their outbound email which can make email a more reliable way to communicate.

DMARC.org’s founding contributors include:

• Receivers: AOL, Comcast, GMail, Hotmail, Yahoo! Mail
• Senders: American Greetings, Bank of America, Facebook, Fidelity, LinkedIn, Paypal
• Intermediaries & Vendors: Agari, Cloudmark, eCert, ReturnPath, Trusted Domain Project

via DMARC.org – Domain-based Message Authentication, Reporting and Conformance.

OpenID Connect defined scopes

OpenID Connect defines several scopes. They are:

• openid - REQUIRED. Informs the Authorization Server that the Client is making an OpenID Connect request. If the openid scope value is not present, the request MUST NOT be treated as an OpenID Connect request. The openid value also requests that the ID Token associated with the authentication session be returned. If the response_type includes token, the ID Token is returned in the Authorization Response along with the Access Token. If the response_type includes code, the ID Token is returned as part of the Token Endpoint response. This scope value requests access to the user_id Claim at the UserInfo Endpoint.
• profile - OPTIONAL. This requests that access to the End-User’s profile Claims excluding the address and email Claims at the UserInfo Endpoint be granted by the issued Access Token.
• email - OPTIONAL. This requests that access to the email and verified Claims at the UserInfo Endpoint be granted by the issued Access Token.
• address - OPTIONAL. This requests that access to address Claim at the UserInfo Endpoint be granted by the issued Access Token.
• phone - OPTIONAL. This requests that access to the phone_number Claim at the UserInfo Endpoint be granted by the issued Access Token.

They can be regarded as the shorthand for the full claims in OpenID Request Object.

OpenID Request Object

The OpenID Request Object is used to provide OpenID request parameters that MAY differ from the default ones. Implementing support for the OpenID Request Object is OPTIONAL. Supporting it is necessary for implementations that need to request or provide sets of Claims other than the default UserInfo, and ID Token Claim sets.

The OpenID Request Object is a JWT [JWT] that is passed as the value of the “request” parameter in the Authorization Request. Parameters that affect the information returned from the UserInfo Endpoint are in the “userinfo” member. Parameters that affect the information returned in the ID Token are in the “id_token” member.

It also includes other OAuth parameters. Thus, in case of scope=openid%20profile, then the equivalent request object will look like:

{
 "response_type": "code id_token",
 "client_id": "s6BhdRkqt3",
 "redirect_uri": "https://client.example.com/cb",
 "scope": "openid profile",
 "state": "af0ifjsldkj",
 "id_token":
   {
     "claims":
       {
        "auth_time": null,
       },
   },
 "userinfo":
   {
     "claims":
       {
         "name": null,
         "nickname": {"optional": true},
         "email": null,
         "verified": null,
         "picture": {"optional": true}
       }
   }
}

Mapping OpenID Connect scopes to Connect claims

So let us go ahead and map the scopes to the claims.

openid

The scope openid can be mapped to id_token claim in the request object. That is:

"id_token": {
  "claims": {
    "auth_time": null
  }
}

Note that there are other claims that can go into id_token member, such as max_age. However, just stating “openid” in the scope is equivalent to requesting this claim set. If you need to specify in finer grain, you have to use request object so that the “id_token” claim will look like:

 "id_token":
   {
     "claims":
       {
        "auth_time": null,
        "acr": { "values":["2"] }
       },
     "max_age": 86400,

   }

 profile

Similarly, the “profile” scope is equivalent to request the following claims in the request object.

 "userinfo":
   {
     "claims":
       {
         "user_id": null,
         "name": {"optional": true},
         "nickname": {"optional": true},
         "profile": {"optional": true},
         "picture": {"optional": true},
         "website": {"optional": true},
         "gender":  {"optional": true},
         "birthday":  {"optional": true},
         "locale":  {"optional": true},
         "zoneinfo":  {"optional": true},
         "updated_time": {"optional": true}
       }
   }

email

As expected, ‘email’ scope is equivalent to the following:

 "userinfo":
   {
     "claims":
       {
         "email": null,
         "verified": null
       }
   }

address

Similarly, ‘address’ scope is equivalent to the following:

 "userinfo":
   {
     "claims":
       {
         "address":
           {
             "formatted": null
           }
        }
    }

Note that there are other optional claims that may go into “address” claim. They are:

• formatted - The full mailing address, formatted for display or use with a mailing label. This field MAY contain newlines. This is the Primary Sub-Field for this field, for the purposes of sorting and filtering.
• street_address - The full street address component, which may include house number, street name, PO BOX, and multi-line extended street address information. This field MAY contain newlines.
• locality - The city or locality component.
• region - The state, province, prefecture or region component.
• postal_code - The zip code or postal code component.
• country - The country name component.

We have not defined the detailed format of those claims because there is no agreed upon universal address system in the world. I even had a problem in having a claim name like “street_address”. You may think that street address is universal, but it is not true. For example, there is no “street address” defined in Japan. It only has residencial address that is assigned to an area with a house ever built. Often, an American asked for an “address” to get to my house when visiting me. Sorry, no luck. Now that you have Google maps that directs you, you can reach my house that way as well, but before, you could not. It is not defined in terms of street, nor they are numbered in sequence. It is an OID for the piece of land with a house. You had to locate the “address” on a map, then find the street that has no name, and try to get there often by counting the number of roads in between, etc. Different countries have different addressing system. It is best left for each country to define their own claims if more structured address claim is needed.

Conclusion

Hopefully, now you have clear idea of the relationship between the “scope” and “claims”.

OpenID Connect scopes can be thought of as the short hands for predefined sets of claims.  They are handy, but sometimes are too blunt. Under such circumstances, you would have to use claims.

You are free to define your own “scopes”. However, I believe that it is a good practice to define claims that maps to it. A custom “scope” is supposed to be defined as a URL. It would be pretty cool if you put the equivalent claim file to the URL so that the semantics of the “scope” would be machine readable.