This page (revision-1) was last changed on 29-Nov-2024 16:16 by UnknownAuthor

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Page revision history

Version Date Modified Size Author Changes ... Change note

Page References

Incoming links Outgoing links

Version management

Difference between version and

At line 1 added 35 lines
!!! Overview[1]
[{$pagename}] ([JOSE]) is a framework intended to provide a method to securely transfer [claims] (such as authorization information) between parties.
[{$pagename}] is also referred to as [JSON Object Signing and Encryption] but the [IETF] Working Group was [{$pagename}]
The [{$pagename}] framework provides a collection of specifications to serve this purpose. A [JSON Web Token] ([JWT]) contains [claims] that can be used to allow a system to apply access control to resources it owns. One potential use case of the [JWT] is as the means of authentication and authorization for a system that exposes resources through an [OAuth 2.0] model.
[JSON Web Token Claims] are a set of key/value pairs that provide a target system with sufficient information about the given client to apply the appropriate level of access control to resources under its ownership. [Claim] names are split into three classes:
* Registered (IANA)
* Public
* Private.
Further details about claims can be found in section 4 of the [JWT] specification.
[JWTs] can be represented as either [JSON Web Signature] ([JWS]) or a [JSON Web Encryption] ([JWE]) objects. Claims within a [JWS] can be read as they are simply base64-encoded (but carry with them a signature for authentication). Claims in a [JWE] on the other hand, are encrypted and as such, are entirely opaque to clients using them as their means of authentication and authorization.
!! [{$pagename}] or [JSON Object] Signing and Encryption
The standard provides a general approach to signing and encryption of any content, not necessarily in [JSON]. However, it is deliberately built on [JSON] and [base64url] to be easily usable in web [applications]. Also, while being used in [OpenID Connect], [{$pagename}] can be used as a building block in other [protocols].
[{$pagename}] is still an evolving standard consists of several [RFCs]:
* [JWS] ([RFC 7515]) - [JSON Web Signature], describes producing and handling signed messages
* [JWE] ([RFC 7516]) - [JSON Web Encryption], describes protecting and handling [encrypted] [messages]
* [JWK] ([RFC 7517]) - [JSON Web Key], describes format and handling of [cryptographic] keys in [{$pagename}]
* [JWA] ([RFC 7518]) - [JSON Web Algorithms], describes [cryptographic] [algorithms] used in [{$pagename}]
* [JWT] ([RFC 7519]) - [JSON Web Token], describes representation of [claims] encoded in JSON and protected by [JWS] or [JWE]
* [JOSE-Cookbook] ([RFC 7520]) (was draft-ietf-jose-cookbook) - [Examples] of Protecting Content Using JSON Object Signing and Encryption ([JOSE])
* [JWK-Thumbprint] ([RFC 7638]) (was draft-ietf-jose-jwk-thumbprint) - [JSON Web Key] ([JWK)] [Thumbprint|JWK-Thumbprint]
* [RFC 7797] (was draft-ietf-jose-jws-signing-input-options) - [JSON Web Signature] ([JWS]) Unencoded Payload Option
* [RFC 8037] - defines how to use the [Diffie-Hellman] [algorithms] "[X25519]" and "[X448]" as well as the signature [algorithms] "[Ed25519]" and "[Ed448]" from the [IRTF] [CFRG] [Elliptic Curves] work in [Javascript Object Signing and Encryption] ([JOSE]).
!! More Information
There might be more information for this subject on one of the following:
[{ReferringPagesPlugin before='*' after='\n' }]
----
* [#1] - [Javascript Object Signing and Encryption (JOSE)|https://jose.readthedocs.org/en/latest/|target='_blank'] - based on information obtained 2015-12-13
* [#2] - [Javascript Object Signing and Encryption (jose) Concluded WG|https://datatracker.ietf.org/wg/jose/documents/|target='_blank'] - based on information obtained 2017-06-17