My 2012 homerun in IT-security: For many years nothing happened in Web security - with respect to security-enabling the HTTP stack. This is not true anymore: game-changing innovations do emerge right now. Their impact will - likely - be pervasive. It is important to understand what exactly is being launched, why this is happening and which forces are driving this. This presentation establishes this context and elaborates on the implications.

1. New Trends in Web Security
Oliver Pfaff
May 10, 2012

2. A Journey through Time – 2000 to 2012
Authentication
Authorization IAM (Identity and
IT-security Access Management)
Federation
▶ Enterprise camp: identities/resources
Has use cases owned by legal entities
driving current
innovation ▶ Internet camp: identities/resources
owned by individual users
May 2012 2

3. Security-Enabling the HTTP Stack -
Until 2010
Protocol stack Security fabric
No help - does match
target environment
WS-*/ Security
WS- infrastructure
Security
HTTP
body
HTTP Security Security
header protocols syntax
SSL/TLS
Security token
TCP Helps - but does not
cover given use cases
IP Meta-information Cryptographic
algorithms
May 2012 3

4. Driving Forces
▶ Constrained clients:
 Smart phones/tablets accessing via mobile networks
 Promote native clients: talk HTTP, serve single users – but are no
classical Web browsers
▶ API economy:
 Content aggregation via mash-ups/composite applications, Web APIs
exposing lightweight interfaces, RESTful Web services – no WS-*
 Promote application clients: talk HTTP, serve multiple users
▶ Cloud:
 Procure IT from the network: applications (SaaS), software (PaaS) or
hardware infrastructure (IaaS)
 For many organizations "owning iron" is a snail’s pace approach. Holds
for the server side (XaaS) and the client side (BYOD)
▶ Disillusion:
 Some things did not fly such as PKI to the end-user:
• Not handy: people do not understand PKI – even IT pro’s struggle
• Compromises: Comodo/DigiNotar/StartTLS CAs, DuQu, Stuxnet
• Ramifications of lemon markets (Nobel prize-awarded theory) apply
May 2012 4

5. …Their Constraints/Needs/Use Cases
▶ Constrained clients:
 Interactions: server-side, no client-side redirections
 Compact representations: new formats for security objects, no WS-*
▶ API economy:
 Authenticate API clients: new authentication schemes for HTTP
3-party scenarios
 Manage access to personal resources: new authorization protocols
 Move identity data (for self): on-boarding of individual users
▶ Cloud:
 Externalize user authentication: provide seamless access (i.e. SSO)
 Manage identity data (for any): user on-boarding in bulk-style
 Manage authorization: govern access control for subscriber resources
▶ Disillusion:
 Alternate entity authentication schemes: stronger than username/static
password, less awkward than public key certificate and private key
 Supply meta-information: express to relying parties how authentication
and identity creation was done
May 2012 5

6. Use Cases Requiring 3-Party Exchanges
▶ Manage access to personal resources
 Prerequisites: user and asserting/relying party authentication
▶ Move identity data (for self)
 Prerequisites: user and asserting/relying party authentication
▶ Externalize user authentication
 Prerequisite: user and asserting party authentication
Personal
App resources
Identity
HTTP
data
UI SSL/ User
App TLS authentication
HTTP TCP/
SSL/ HTTP IP
TLS Asserting party
TCP/ SSL/
IP TLS
TCP/
User agent
IP
Relying party
May 2012 6

7. 3-Party Exchange Pattern –
Functional Requirements
User ▶ Facilitate 3-party overlay:
Authn agent  User agent to asserting party - security
with Provide endpoint:
creds grant
• Entitle relying party after
authenticating
• UI-style: entitlement dialogue with
arbitrary Web user authentication
Asserting  Relying party to asserting party -
party security endpoint:
Entitle- Security Resource • Obtain security token after
ment endpoint endpoint authenticating
• API-style: new protocols with
Provide arbitrary Web client authentication
token Authn  Relying party to asserting party –
with resource endpoint:
token • Obtain resource access after
authenticating
Authn
with • API-style: new authentication
creds Relying protocols (token-based)
party
May 2012 7

8. 3-Party Exchange Pattern –
Non-Functional Requirements
▶ 3-party exchanges between relying and
asserting parties – via user agents esp.
3-party exchanges: constrained clients:
Sub- HTTP  Use HTTP 3xx redirects
HTTP
 Employ URL query parameters for
Hdr. Body exchange of security token acquisition
N.a.
objects and their responses
▶ Subsequent 2-party exchanges between
URL N.a.
relying and asserting parties:
query
 Use HTTP Authorization headers for
authentication purposes based on
security tokens
2-party exchanges: ▶ URL query parameters as well as HTTP
Sub- HTTP Authorization headers are space-
HTTP constrained:
Hdr. Body
 Objects to acquire and utilize security
SSL/ tokens must match these constraints
TLS  Note: SAML assertion/protocol syntax
Authn Var. objects are suspect of violating them
header
May 2012 8

9. Identifying the New Entrants
▶ Constrained clients:
 Interactions: N.a.
 Compact representations: JWA, JWE, JWK, JWS (IETF jose WG) and JWT (IETF
individual submission)
▶ API economy:
 Authenticate API clients: HTTP Bearer and MAC authentication (IETF oauth WG)
 Manage access to personal resources: OAuth (IETF oauth WG), UMA (Kantara)
 Move identity data (for self): OpenID Connect (OpenID)
▶ Cloud:
 Externalize user authentication: OpenID Connect (OpenID)
 Manage identity data (for any): SCIM (IETF WG candidate)
 Manage authorization: XACML 3.0 administration and delegation profile (OASIS)
▶ Disillusion:
 Alternate authentication schemes: TOTP (RFC 6238), HOTP (RFC 4226),
callbacks (custom)
 Supply meta-information: assurance levels (NIST SP800-63, ITU-T X.1254 |
ISO/IEC 29115, Kantara IAF)
May 2012 9

10. Layering the New Entrants
Use case-specific
Generic
May 2012 10

11. Security Fabric for the HTTP Stack –
From ca. 2012
Provides request
authn
JWS
IETF Draft
HTTP request
authn
IETF Draft
Provides entity JWE
IETF Draft
authentication
Provides service for managing Provides
token
Security token authn
Security token
service <Abstract>
<Abstract>
Provides token
Instantiates Instantiates
encryption
OAuth authz JWT
UMA
Promotes server IETF individual
Kantara IETF Draft submission
Draft Includes
OpenID
OAuth
Connect Extends
IETF Draft
OpenID
Draft
May 2012 11

12. Security Fabric for the SOAP Stack –
From ca. 2007 (for reference purposes)
Provides msg
Allows publishing of authn XML Signature
W3C standard
SOAP Message Provides msg
WS-Policy WS-SecurityPolicy Security encryption
W3C OASIS standard OASIS standard
standard (WS-SX TC) (WSS TC)
Defines Allows profiling of
Provides entity XML Encryption
security for W3C standard
authentication
STSs
Provides service for managing Provides
token
Security token authn
Security token
service <Abstract>
<Abstract>
Provides token
Instantiates
Instantiates encryption
SAML assertion
WS-Trust
OASIS standard
OASIS standard
(SAML TC)
(WS-SX TC)
Extends
WSFED
OASIS committee
specification
May 2012 12

13. Security-Enabling the HTTP Stack -
From ca. 2012
Protocol stack Security fabric
Security
infrastructure
HTTP
body
HTTP Security Security
header protocols syntax
SSL/TLS
Security token
TCP
Meta-information Cryptographic
IP
algorithms
May 2012 13

14. Is It Real?
▶ 4-party security protocol examples:
– UMA: http://kantarainitiative.org/confluence/display/uma/UMA+Implementations
▶ 3-party security protocol examples:
– OIDC relying party: http://www8322u.sakura.ne.jp/oidconnect/
– OIDC asserting party: http://oauthssodemo.appspot.com/step/1
– OAuth relying party: https://twitter.com/#!/who_to_follow/import/
– OAuth asserting party: https://accounts.google.com/OAuthAuthorizeToken
▶ 2-party security protocol examples:
– HTTP Bearer authentication: cf. OpenID Connect sample
– HTTP MAC authentication: N.a. - current implementations utilize HTTP Bearer.
▶ Security infrastructure examples:
– OAuth authorization server: cf. OpenID Connect sample
▶ Security token examples:
– JWT: cf. OpenID Connect sample
▶ Meta-information syntax examples:
– LoA: N.a.
▶ Security syntax examples:
– JWA/E/K/S: cf. OpenID Connect sample
May 2012 14

15. Conclusions
▶ It is amazing what is happening right now – security-wise as well as IAM-wise
▶ The current innovation is triggered by use cases from the Internet IAM camp. In
particular, it addresses needs related to Web 2.0 as well as social networks
▶ This does not imply that the emerging mechanisms are limited to these domains:
– Other industries have matching use cases e.g. user-managed access to
medical data to-be-shared among healthcare providers (ECRs – Electronic
Case Records)
– Their resolution delivers security mechanisms that can be (re-)used in other
use cases
– Security functionality for 3-party Web exchanges presents a main focus. Such
3-party exchanges also apply in other industries – probably with some other
details but likely requiring similar patterns and approaches.
▶ The evolution of specifications, implementation of toolkits (many open source)
and supply of services on the Internet happens in parallel
▶ This innovation in Web security is still ongoing and not yet concluded
May 2012 15

16. Abbreviations
AJAX Asynchronous JavaScript And XML
API Application Programming Interface
AWS Amazon Web Services
BYOD Bring Your Own Device
CA Certification Authority
CMS Cryptographic Message Syntax
ECC Elliptic Curve Cryptography
HMAC Hash-based Message Authentication Code
HOTP HMAC-based OTP
HTML HyperText Markup Language
HTTP HyperText Transfer Protocol
IaaS Infrastructure as a Service
IAF Identity Assurance Framework
IAM Identity and Access Management
JOSE JavaScript Object Signing and Encryption
JSON JavaScript Object Notation
JWA/E/K/S/T JSON Web Algorithms/Encryption/Key/Signature/Token
LoA Level of Assurance
OATH Open Authentication
OAuth Open Authorization
May 2012 16

17. Abbreviations (cont’d)
OIDC OpenID Connect
OTP OneTime Password
PaaS Platform as a Service
PKCS Public-Key Cryptography Standards
PKI Public Key Infrastructure
PoP Proof-of-Possession
REST REpresentational State Transfer
SaaS Software as a Service
SAML Security Assertion Markup Language
SCIM Simple Cloud Identity Management
SOAP Simple Object Access Protocol
SSL Secure Sockets Layer
STS Security Token Service
TLS Transport Layer Security
TOTP Time-based OTP
UMA User-Managed Access
URL Uniform Resource Locator
WS Web Services
XaaS Any X offered ’as-a-Service’
XML eXtensible Markup Language
May 2012 17

18. Background
▶ Fielding, R.: Architectural Styles and the Design of Network-based Software
Architectures. PhD Thesis. University of California, Irvine, 2000.
▶ Gutmann, P.: PKI: Lemon Markets and Lemonade. RSA Security Conference 2011.
▶ Jones, M.: The Emerging JSON-Based Identity Protocol Suite. W3C Workshop on
Identity in the Browser, 2011.
▶ Machulak, M.P. et al.: User-Managed Access to Web Resources. Proceedings of the
6th ACM Workshop on Digital Identity Management, 2010.
▶ Mash-up directory: http://www.programmableweb.com/mashups/directory
▶ Pautasso, C.; Zimmermann, O.; Leymann, F.: RESTful Web Services vs. “Big” Web
Services: Making the Right Architectural Decision. Proc. of the 17th International
World Wide Web Conference, Bejing, 2008.
▶ Prins, J.R.: DigiNotar Certificate Authority breach “Operation Black Tulip”. Interim
Report: Investigation DigiNotar Certificate Authority Environment, 2011.
▶ Rabin, J.; McCathieNevile, C. (eds.): Mobile Web Best Practices 1.0. W3C
Recommendation 2008.
▶ Rutkowski, M. (ed.): Identity in the Cloud Use Cases Version 1.0. OASIS
Committee Note, 2012.
▶ Web API directory: http://www.programmableweb.com/apis/directory
▶ Yegge, S.: Stevey's Google Platforms Rant. 2011
May 2012 18

19. Author
Oliver Pfaff, oliver.frank.pfaff@gmail.com
May 2012 19

20. Web Application Styles
Traditional AJAX-aware Mobile Mash-up
Web browser Web browser Native client Application client
UI UI UI HTTP server
JavaScript HTML or
HTML HTML JSON,XML JSON,XML
HTTP client AJAX engine HTTP client Business logic
Request JSON,XML
Request JSON,XML
HTTP client HTTP client
Request Request
Response Response Response Response
(HTML) (JSON, XML) (JSON, XML) (JSON, XML)
HTTP server HTTP server HTTP server HTTP server
Web server Web server Web server Web server
UI-style IO API-style IO
May 2012 20

21. Characterizing Client-Side Components
▶ Web browsers:
– HTTP client with address bar, serves resources of arbitrary services
– HTML as primary media type (UI-style)
– Client-side scripting support
– Serves #1 simultaneous user
– Examples: Google Chrome, Microsoft Internet Explorer, Mozilla Firefox
▶ Native clients:
– HTTP client without address bar, serves resources of a specific service
– HTML (UI-style) or JSON/XML as primary media type (API-style)
– Serves #1 simultaneous user
– Example: Android/iPhone Web apps
▶ Application clients:
– HTTP client and server
– JSON/XML as primary media type towards downstream application (API-style)
– Provides own application/business functionality (i.e. not only a HTTP proxy)
– Serves #n simultaneous users
– Example: Amazon & eBay comparison shopping
May 2012 21

22. Security Fabric for the HTTP Stack –
Until 2010
▶ Security fabric is broadly absent in the actual HTTP layer:
– HTTP Basic authentication: username/password-based authentication
• Transfers credentials in plain (to be precise: Base64 encoded)
• Unpopular: HTML form-based authentication is preferred
– HTTP Digest authentication: shared secret key-based authentication
• Not used in practice
– Custom HTTP authentication methods: Kerberos/NTLM-based authentication
• Used for integrated Windows authentication
– HTTP session state mechanisms:
• No actual security mechanism but a factor in the security fingerprint
▶ Security fabric is present:
– Underneath the HTTP layer: SSL/TLS
– Above the HTTP layer: WS-Security
▶ Caveats:
– Underneath the HTTP layer: hard to support complex use cases
– Above the HTTP layer: adds significant infrastructural burden
May 2012 22

23. 4-Party Security Protocols –
User-Managed Access - UMA
▶ UMA refines OAuth 2.0:
– Allows users to manage access to individual resources, residing on any number
of OAuth resource servers, through a single OAuth authorization server
– Extends OAuth by formalizing interactions between OAuth resource and
authorization servers (underspecified in OAuth)
– Promotes OAuth authorization servers to independent network services – hence
turns the 3-party protocol OAuth into a 4-party protocol
– Extends the OAuth notion of scope and hence enhances the granularity of
access control
– More information: Comparing OAuth and UMA, UMA Frequently Asked Questions
▶ The specifications are developed by a Kantara working group:
– User-Managed Access (UMA) Core Protocol (Draft 2012 also published as IETF
Draft - individual submission)
– UMA Trust Model (Draft 2012)
– UMA Scenarios and Use Cases (Draft 2010)
– UMA User Stories (Draft 2010)
▶ Familiar to: -
May 2012 23

24. 3-Party Security Protocols –
OpenID Connect
▶ OpenID Connect defines an identity layer on top of OAuth 2.0:
– Exploits and extends OAuth for a specific kind of resources: data specific to user
authentication and user identity (e.g. data persisted in user accounts)
– Turns a solution for the delegation use case in access management into an
approach for the federation use case in identity management
▶ The specifications are developed by the OpenID community:
– Basic Client Profile (Draft 2012)
– Discovery (Draft 2012)
– Dynamic Registration (Draft 2012)
– Standard (Draft 2012)
– Messages (Draft 2012)
– Session Management (Draft 2012)
▶ Familiar to: SAML, WS-Federation (passive profile), OpenID (note: it’s relation to
the original OpenID protocol is loose)
▶ More information: OpenID Connect - An Emperor Or Just New Cloths?
May 2012 24

25. 3-Party Security Protocols –
OpenID Connect Exchange Pattern
2. Authn with user credentials, User 1. Redirect user agent to
delegate access to identity data agent OAuth authz endpoint,
provide oidc:Request
object
4. Redirect user agent to
relying party with
oauth:Grant
Asserting
party
Security UserInfo
3. Store entitlement
endpoint endpoint
6. Respond with 9. Respond with user info
oauth:AccessToken,
oidc:IdToken
5. Authn with client 8. Authn with
credentials, supply oauth:AccessToken,
oauth:Grant, request request user info
oauth:AccessToken,
oidc:IdToken
Relying
7. Consume oidc:IdToken party 10. Process user info
May 2012 25

26. 3-Party Security Protocols –
OAuth
▶ OAuth allows resource owners to delegate resource access rights to third-party
consumers (such as composite applications in a mash-up) in a discretionary
fashion with a limited scope (functionality, time).
▶ The specifications are developed by the IETF oauth working group:
– The OAuth 2.0 Authorization Framework (Draft 2012)
– The OAuth 1.0 Protocol (RFC 5849, 2010)
▶ Familiar to: -
▶ More information: Analyzing OAuth
May 2012 26

27. 3-Party Security Protocols –
OAuth Exchange Pattern
2. Authn with user credentials, User 1. Redirect user agent to
delegate access to resource agent OAuth authz endpoint
4. Redirect user agent to
relying party with
oauth:Grant
Asserting
party
Security Resource
3. Store entitlement
endpoint endpoint
6. Respond with 8. Respond with resource
oauth:AccessToken
5. Authn with client 7. Authn with
credentials, supply oauth:AccessToken,
oauth:Grant, request request resource
oauth:AccessToken
Relying
party 9. Process resource
May 2012 27

28. 2-Party Security Protocols –
HTTP Bearer Authentication
▶ OAuth-defined mechanism extending the HTTP access authentication framework
(RFC 2616) – may be used independent of OAuth:
– WWW-Authenticate response header: specifies the authentication method
(Bearer) and allows to specify realm and scope parameters
– Authorization request header: transfers a bearer token in Base64 encoding
▶ Bearer tokens:
– Any party in possession of the token can use it to get access to the associated
resources - without demonstrating possession of a cryptographic key
– Supported form-factors:
• SAML Assertion objects (self-contained security token)
• JSON Web tokens (self-contained security token)
▶ The specifications are developed by the IETF oauth working group:
– The OAuth 2.0 Authorization Protocol: Bearer Tokens (Draft 2012)
– SAML 2.0 Bearer Assertion Profiles for OAuth 2.0 (Draft 2012)
– JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0 (Draft 2012)
▶ Familiar to: -
May 2012 28

29. 2-Party Security Protocols –
HTTP MAC Authentication
▶ OAuth-defined mechanism extending the HTTP access authentication framework
(RFC 2616) – may be used independent of OAuth:
– WWW-Authenticate response header: specifies the authentication method
(MAC)
– Authorization request header: transfers a symmetric cryptographic
checksum over portions of the HTTP request
▶ MAC tokens:
– Any party using the token needs to demonstrate possession of a
cryptographic key. Keying associations are established out-of-band or employ
OAuth access tokens.
– Supported form-factor: identifier token
▶ The specification is developed by the IETF oauth working group:
– HTTP Authentication: MAC Access Authentication (Draft 2012)
▶ Familiar to:
 HTTP Digest authentication (RFC 2617, does require a user password)
 HTTP OAuth authentication (RFC 5849, a predecessor)
 HTTP AWS authentication (AWS proprietary)
May 2012 29

30. 2-Party Security Protocols –
OTP Authentication
▶ HOTP, TOTP and OCRA define the exchanges between claimants and verifiers in
order to establish shared secret key-based entity authentication - without binding
the exchanges to an actual transfer protocol (typical implementations use HTTP
through HTML forms):
– HOTP: event-based OTPs
– TOTP: time-based OTPs
– OCRA: challenge/response-based OTPs
▶ PSKC and DSKPP define means to establish and manage the underlying keying
associations.
▶ The specifications are developed by the OATH community and brought into IETF:
– HOTP: An HMAC-Based OTP Algorithm (RFC 4226, 2005)
– TOTP - Time-based One-time Password Algorithm (RFC 6238, 2011)
– OCRA - OATH Challenge/Response Algorithms Specification (RFC 6287, 2011)
– PSKC - Portable Symmetric Key Container (RFC 6030, 2010)
– DSKPP - Dynamic Symmetric Key Provisioning Protocol (RFC 6063, 2010)
▶ Familiar to: RFC 2289, vendor-proprietary solutions
May 2012 30

31. Security Infrastructure –
OAuth Authorization Server
▶ To decouple resource server tasks from OAuth-tasks, OAuth 2.0 introduces the
authorization server as a distinguished entity with following endpoints:
– Authorization endpoint: entitle 3rd-party clients, resource owner-facing
– Token endpoint: acquire access tokens (initial, refresh), relying party-facing
▶ OpenID Connect extends the OAuth authorization server abstraction by adding:
– UserInfo endpoint: query identity data, relying party-facing
– CheckID endpoint: query and validate ID token objects, relying party-facing
– Refresh session endpoint: refresh ID token objects, relying party-facing
– End session endpoint: terminate sessions at IdPs, relying party-facing
▶ By extension (further token types, use cases, explicit system interfaces and
network protocol), it may evolve towards a security infrastructure service:
– It supports the underlying use cases (delegation use case in access
management, federation use case in identity management)
– But is not limited to them and presents a security infrastructure service nucleus
– Kantara UMA is already going this direction
▶ The specifications are developed by the IETF oauth working group:
– The OAuth 2.0 Authorization Framework (Draft 2012)
▶ Familiar to: WS-Trust STS
May 2012 31

32. Security Token –
JSON Web Token - JWT
▶ JWT defines self-contained security tokens for space-constrained environments:
– Uses JSON data structures (RFC 4627) to represent identity-related information
about a subject for transfer from an asserting to a relying party.
– Embody (name, value)-pairs – called claims - to express identity-related data:
• Claim names:
o Define some reserved claim names e.g. exp (expiration time)
Support IANA-registered public claim names
o
o Allow private claim names
• Claim values: JSON-defined data types esp. literal (string, number, Boolean)
or complex (object, array) types
– JWT may be signed (JSON Web Signature) and/or encrypted (JSON Web
Encryption)
– JWT supports the bearer model but does not yet support PoP
▶ The specification is currently provided as individual submission to the IETF jose
working group:
– JSON Web Token (JWT) (Draft 2012)
▶ Familiar to: SAML Assertion
May 2012 32

33. Meta-Information Syntax –
Level of Assurance - LoA
▶ Level of assurance specifications allow asserting parties to express how
authentication and identity creation was done:
– They establish mutually understood levels along with applicable criteria:
• LoA-1: Little or no confidence in the asserted identity e.g. self-asserted
identity from OpenId IdP
• LoA-2: Some confidence in the asserted identity e.g. third-party asserted
identity from SAML IdP (bearer token, single factor initial authentication)
• LoA-3: High confidence in the asserted identity e.g. third-party asserted
identity from SAML IdP (bearer token, multi-factor initial authentication)
• LoA-4: Very high confidence in the asserted identity e.g. third-party asserted
identity from SAML IdP (PoP token, multi-factor initial authentication)
– The qualification encompasses enrolment, credential management, and entity
authentication phases
▶ Specifications are developed by NIST, ITU-T | ISO/IEC, and Kantara:
– NIST SP800-63 Electronic Authentication Guideline (2006)
– ITU-T X.1254 | ISO/IEC 29115 – Entity authentication assurance framework
(Draft 2012)
– Kantara Identity Assurance Framework (2010)
▶ Familiar to: -
May 2012 33

34. Security Syntax –
JSON Web Signature - JWS
▶ JSON Web Signature defines a compact digital signature format addressing
space-constrained environments:
– Uses JSON data structures to represent signed data of arbitrary type along
with validation meta-data
– Per JWS object, a single data object can be signed
– Supports the enveloping of signed data (JWS object wraps signed data) but
does not yet support enveloped and detached signed data
– Allows to refer to validation keys by-reference (JSON Web Key URL, X.509
certificate path URL, identifier, thumbprint) or by-value (JSON Web Key
object, X.509 certificate path)
– Supports symmetric as well as asymmetric checksums e.g.
• HMAC-SHA256
• RSA-SHA256
• ECDSA-SHA-256 (NIST P-256)
▶ The specification is developed by the IETF jose working group:
– JSON Web Signature (JWS) (Draft 2012)
▶ Familiar to: XML Signature, PKCS#7/CMS
May 2012 34

35. Security Syntax –
JSON Web Key - JWK
▶ JSON Web Key defines a compact public key representation format addressing
space-constrained environments:
 Uses JSON data structures to represent public keys (in plain form, not in form
of public key certificates)
▶ The specification is developed by the IETF jose working group:
– JSON Web Key (JWK) (Draft 2012)
▶ Familiar to: XML Signature (ds:KeyInfo portion)
May 2012 35

36. Security Syntax –
JSON Web Encryption - JWE
▶ JSON Web Encryption defines a compact encryption format addressing space-
constrained environments:
– Uses JSON data structures to represent encrypted data of arbitrary type along
with decryption meta-data
– Allows to refer to decryption keys by-reference (JSON Web Key URL, X.509
certificate path URL, identifier, thumbprint) or by-value (JSON Web Key object,
X.509 certificate path)
– Encrypts payload through an indirection (content/key encryption)
– Can also integrate HMAC-based message authentication (first-encrypt-then-
sign)
▶ The specification is developed by the IETF jose working group:
– JSON Web Encryption (JWE) (Draft 2012)
▶ Familiar to: XML Encryption, PKCS#7/CMS
May 2012 36

37. Security Syntax –
JSON Web Algorithms - JWA
▶ JSON Web Algorithm defines descriptors for cryptographic algorithms
– For use with JSON Web Encryption and Signature
▶ The specification is developed by the IETF jose working group:
– JSON Web Algorithms (JWA) (Draft 2012)
▶ Familiar to: n.a. (handled inline by XML and ASN.1-based security syntax
specifications)
May 2012 37