New Trends in Web Security
9 likes4,616 views
This document discusses new trends in web security from 2000 to 2012, focusing on the evolution of authentication, authorization, and identity management driven by various factors, including constrained clients and the API economy. It outlines the emergence of 3-party security protocols such as OpenID Connect and OAuth, and the shift towards user-managed access for improved security and flexibility. The text emphasizes ongoing innovations in security mechanisms for web exchanges, illustrating their applicability across different industries beyond those related to the internet.
New Trends in Web Security
- 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
- 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