On-Behalf-Of Semantics for JSON Web Tokens (JWTs)
draft-jones-on-behalf-of-jwt-00

Abstract

This specification defines how to express the claim that one principal is allowed to act on behalf of another principal in a defined context using JSON Web Tokens (JWTs) (Jones (editor), M., Balfanz, D., Bradley, J., Goland, Y., Panzer, J., and N. Sakimura, “JSON Web Token (JWT),” October 2010.) [JWT].

Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [RFC2119].

Status of this Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

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 29, 2011.

Copyright Notice

Copyright (c) 2010 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 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

1.  Introduction
2.  On-Behalf-Of vs. Impersonation Semantics
3.  on-behalf-of claims
4.  IANA Considerations
5.  Security Considerations
6.  Normative References
§  Authors' Addresses

1.  Introduction

This specification defines how to express the claim that one principal is allowed to act on behalf of another principal in a defined context using JSON Web Tokens (JWTs) (Jones (editor), M., Balfanz, D., Bradley, J., Goland, Y., Panzer, J., and N. Sakimura, “JSON Web Token (JWT),” October 2010.) [JWT].

{
 "obo":
 {
  "prn":"mailto:joe@example.com",
  "ctx":["urn:adatum.com:calendar"]
 }
}

In this example, the "obo" (on-behalf-of) claim would be included in a JWT's claims section. The claim states that the holder of the bearer token has the right to act on behalf of the principal mailto:joe@example.com in the context of the service type urn:adatum.com:calendar.

2.  On-Behalf-Of vs. Impersonation Semantics

When principal A acts on behalf of principal B, A is given all the rights that B has within some defined rights context. With on-behalf-of semantics, principal A still has its own identity separate from B and it is explicitly understood that while B may have delegated its rights to A, any actions taken are being taken by A and not B. In a sense, A is an agent for B.

On-behalf-of semantics are therefore different than impersonation semantics, with which it is sometimes confused. When principal A impersonates principal B, then in so far as any entity receiving claims is concerned, they are actually dealing with B. It is true that some members of the identity system might have awareness that impersonation is going on but it is not a requirement. For all intents and purposes, A is B.

3.  on-behalf-of claims

An on-behalf-of claim made in a JWT consists of a child member of the root JSON object with the member name "obo" (on-behalf-of). The "obo" claim MUST contain the two child members, "prn" (principal) and "ctx" (context). "obo" MAY contain other child members.

If a JWT processor receives an "obo" claim with an unrecognized child member, then this means the "obo" claim is invalid and unless separate semantics have been applied, an invalid "obo" claim MUST cause the entire JWT to be rejected for processing.

The "prn" (principal) child member MUST have a value that is a URI (as defined in RFC 3986 (Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” January 2005.) [RFC3986]). The semantics of this URI is that it identifies the principal for whom the bearer of the JWT is acting on behalf of.

The "ctx" (context) child member MUST have a value that is an array of strings, each of which MUST be a URI. All "ctx" value arrays MUST contain at least one URI. The members of the array define permission contexts in which the bearer is allowed to act on behalf of the principal. The definition of these contexts is outside the scope of this specification.

There is not necessarily a conflict between including an "obo" claim along with claims about the identity of the bearer of the token. The former provides a right - the later information about the identity of the principal that can exercise that right.

However, as with any claims, the relationship between "obo" and other claims is not defined implicitly. Rather an explicit definition must be provided in order for the combined semantics to be understood.

4.  IANA Considerations

The claim "obo" is to be registered in the JWT JSON Web Token Claims registry as defined in the JWT (Jones (editor), M., Balfanz, D., Bradley, J., Goland, Y., Panzer, J., and N. Sakimura, “JSON Web Token (JWT),” October 2010.) [JWT] specification.

5.  Security Considerations

All of the normal security issues, especially in relationship to comparing URIs and dealing with unrecognized values, that are discussed in JWT (Jones (editor), M., Balfanz, D., Bradley, J., Goland, Y., Panzer, J., and N. Sakimura, “JSON Web Token (JWT),” October 2010.) [JWT] also apply here.

In addition, on-behalf-of introduces its own unique security issues. Any time one principal is delegated the rights of another principal, the potential for abuse is always a concern. That is why the "ctx" (context) member is mandatory and must contain at least one value. The context values restrict the contexts in which the delegated rights are to be exercised. The specification explicitly precludes omitting the "ctx" member in order to ensure that there is always some context by which the delegated rights are constrained.

6. Normative References

Authors' Addresses