idnits 2.17.1 draft-thaler-rats-architecture-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC4949]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 14, 2019) is 1656 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-19) exists of draft-ietf-teep-architecture-03 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Thaler 3 Internet-Draft Microsoft 4 Intended status: Informational October 14, 2019 5 Expires: April 16, 2020 7 Remote Attestation Architecture 8 draft-thaler-rats-architecture-00 10 Abstract 12 In network protocol exchanges, it is often the case that one entity 13 (a relying party) requires evidence about the remote peer (and system 14 components [RFC4949] thereof), in order to assess the trustworthiness 15 of the peer. This document describes an architecture for such remote 16 attestation procedures (RATS), which enable relying parties to decide 17 whether to consider a remote system component trustworthy or not. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on April 16, 2020. 36 Copyright Notice 38 Copyright (c) 2019 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 3.1. Network Endpoint Assessment . . . . . . . . . . . . . . . 4 57 3.2. Confidential Machine Learning (ML) Model Protection . . . 4 58 3.3. Confidential Data Retrieval . . . . . . . . . . . . . . . 5 59 3.4. Critical Infrastructure Control . . . . . . . . . . . . . 5 60 3.5. Trusted Execution Environment (TEE) Provisioning . . . . 5 61 3.6. Hardware Watchdog . . . . . . . . . . . . . . . . . . . . 6 62 4. Serialization Formats . . . . . . . . . . . . . . . . . . . . 6 63 5. Architectural Models . . . . . . . . . . . . . . . . . . . . 7 64 5.1. Passport Model . . . . . . . . . . . . . . . . . . . . . 7 65 5.2. Background-Check Model . . . . . . . . . . . . . . . . . 8 66 5.3. Combinations . . . . . . . . . . . . . . . . . . . . . . 9 67 6. Trust Model . . . . . . . . . . . . . . . . . . . . . . . . . 10 68 7. Conceptual Messages . . . . . . . . . . . . . . . . . . . . . 11 69 7.1. Evidence . . . . . . . . . . . . . . . . . . . . . . . . 11 70 7.2. Endorsements . . . . . . . . . . . . . . . . . . . . . . 11 71 7.3. Attestation Results . . . . . . . . . . . . . . . . . . . 12 72 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 73 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 74 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 75 11. Informative References . . . . . . . . . . . . . . . . . . . 13 76 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 78 1. Introduction 80 In network protocol exchanges, it is often the case that one entity 81 (a relying party) requires evidence about the remote peer (and system 82 components [RFC4949] thereof), in order to assess the trustworthiness 83 of the peer. Remote attestation procedures (RATS) enable relying 84 parties to establish a level of confidence in the trustworthiness of 85 remote system components through the creation of attestation evidence 86 by remote system components and a processing chain towards the 87 relying party. A relying party can then decide whether to consider a 88 remote system component trustworthy or not. 90 To improve the confidence in a system component's trustworthiness, a 91 relying party may require evidence about: 93 - system component identity, 95 - composition of system components, including nested components, 96 - roots of trust, 98 - assertion/claim origination or provenance, 100 - manufacturing origin, 102 - system component integrity, 104 - system component configuration, 106 - operational state and measurements of steps which led to the 107 operational state, or 109 - other factors that could influence trust decisions. 111 This document discusses an architecture for describing solutions for 112 this problem. 114 2. Terminology 116 This document uses the following terms: 118 - Attestation: A process by which one entity (the "Attester") 119 provides evidence about its identity and health to another entity, 120 which then assesses its trustworthiness. 122 - Attestation Result: The evaluation results generated by a 123 Verifier, typically including information about an Attester, where 124 the Verifier vouches for the validity of the results. 126 - Attester: An entity whose attributes must be evaluated in order to 127 determine whether the entity is considered healthy or authorized 128 to access a resource. 130 - Evidence: A set of information about an Attester that is to be 131 evaluated by a Verifier. 133 - Relying Party: An entity that depends on the validity of 134 information about another entity, typically for purposes of 135 authorization. Compare /relying party/ in [RFC4949]. 137 - Security policy: A set of rules that direct how a system evaluates 138 the validity of information about another entity. Compare 139 /security policy/ in [RFC4949]. 141 - Verifier: An entity that evaluates the validity of information 142 about an Attester. 144 3. Use Cases 146 This section covers a number of representative use cases for 147 attestation, independent of solution. The purpose is to provide 148 motivation for various aspects of the architecture presented in this 149 draft. Many other use cases exist, and this document does not intend 150 to have a complete list, only to have a set of use cases that 151 collectively cover all the functionality required in the 152 architecture. 154 Each use case includes a description, and a summary of what an 155 Attester and a Relying Party refer to in the use case. 157 3.1. Network Endpoint Assessment 159 Network operators want a trustworthy report of identity and version 160 of information of the hardware and software on the machines attached 161 to their network, for purposes such as inventory, auditing, and/or 162 logging. The network operator may also want a policy by which full 163 access is only granted to devices that meet some definition of 164 health, and so wants to get claims about such information and verify 165 their validity. Attestation is desired to prevent vulnerable or 166 compromised devices from getting access to the network and 167 potentially harming others. 169 Typically, solutions start with some component (called a "Root of 170 Trust") that provides device identity and protected storage for 171 measurements. They then perform a series of measurements, and 172 express this with Evidence as to the hardware and firmware/software 173 that is running. 175 - Attester: A device desiring access to a network 177 - Relying Party: A network infrastructure device such as a router, 178 switch, or access point. 180 3.2. Confidential Machine Learning (ML) Model Protection 182 A device manufacturer wants to protect its intellectual property in 183 terms of the ML model it developed and that runs in the devices that 184 its customers purchased, and it wants to prevent attackers, 185 potentially including the customer themselves, from seeing the 186 details of the model. 188 This typically works by having some protected environment in the 189 device attest to some manufacturer service. If attestation succeeds. 190 then the manufacturer service releases either the model, or a key to 191 decrypt a model the Attester already has in encrypted form, to the 192 requester. 194 - Attester: A device desiring to run an ML model to do inferencing 196 - Relying Party: A server or service holding ML models it desires to 197 protect 199 3.3. Confidential Data Retrieval 201 This is a generalization of the ML model use case above, where the 202 data can be any highly confidential data, such as health data about 203 customers, payroll data about employees, future business plans, etc. 204 Attestation is desired to prevent leaking data to compromised 205 devices. 207 - Attester: An entity desiring to retrieve confidential data 209 - Relying Party: An entity that holds confidential data for 210 retrieval by other entities 212 3.4. Critical Infrastructure Control 214 In this use case, potentially dangerous physical equipment (e.g., 215 power grid, traffic control, hazardous chemical processing, etc.) is 216 connected to a network. The organization managing such 217 infrastructure needs to ensure that only authorized code and users 218 can control such processes, and they are protected from malware or 219 other adversaries. When a protocol operation can affect some 220 critical system, the device attached to the critical equipment thus 221 wants some assurance that the requester has not been compromised. As 222 such, attestation can be used to only accept commands from requesters 223 that are within policy. 225 - Attester: A device or application wishing to control physical 226 equipment. 228 - Relying Party: A device or application connected to potentially 229 dangerous physical equipment (hazardous chemical processing, 230 traffic control, power grid, etc. 232 3.5. Trusted Execution Environment (TEE) Provisioning 234 A "Trusted Application Manager (TAM)" server is responsible for 235 managing the applications running in the TEE of a client device. To 236 do this, the TAM wants to verify the state of a TEE, or of 237 applications in the TEE, of a client device. The TEE attests to the 238 TAM, which can then decide whether the TEE is already in compliance 239 with the TAM's latest policy, or if the TAM needs to uninstall, 240 update, or install approved applications in the TEE to bring it back 241 into compliance with the TAM's policy. 243 - Attester: A device with a trusted execution environment capable of 244 running trusted applications that can be updated. 246 - Relying Party: A Trusted Application Manager. 248 3.6. Hardware Watchdog 250 One significant problem is malware that holds a device hostage and 251 does not allow it to reboot to prevent updates to be applied. This 252 is a significant problem, because it allows a fleet of devices to be 253 held hostage for ransom. 255 A hardware watchdog can be implemented by forcing a reboot unless 256 attestation to a remote server succeeds within a periodic interval, 257 and having the reboot do remediation by bringing a device into 258 compliance, including installation of patches as needed. 260 - Attester: The device that is desired to keep from being held 261 hostage for a long period of time. 263 - Relying Party: A remote server that will securely grant the 264 Attester permission to continue operating (i.e., not reboot) for a 265 period of time. 267 4. Serialization Formats 269 The following diagram illustrates a relationship to which attestation 270 is desired to be added: 272 +-------------+ +-------------+ 273 | |-------------->| | 274 | Attester | Access some | Relying | Evaluate request 275 | | resource | Party | against security policy 276 +-------------+ +-------------+ 278 Figure 1: Typical Resource Access 280 In this diagram, the protocol between Attester and a Relying Party 281 can be any new or existing protocol (e.g., HTTP(S), COAP(S), 802.1x, 282 OPC UA, etc.), depending on the use case. Such protocols typically 283 already have mechanisms for passing security information for purposes 284 of authentication and authorization. Common formats include JWTs 285 [RFC7519], CWTs [RFC8392], and X.509 certificates. 287 To enable attestation to be added to existing protocols, enabling a 288 higher level of assurance against malware for example, it is 289 important that information needed for evaluating the Attester be 290 usable with existing protocols, which have constraints around what 291 formats they can transport. For example, OPC UA [OPCUA] (probably 292 the most common protocol in industrial IoT environments) is defined 293 to carry X.509 certificates and so security information must be 294 embedded into an X.509 certificate to be passed in the protocol. 295 Thus, attestation-related information could be natively encoded in 296 X.509 certificate extensions, or could be natively encoded in some 297 other format (e.g., a CWT) which in turn is then encoded in an X.509 298 certificate extension. 300 Especially for constrained nodes, however, there is a desire to 301 minimize the amount of parsing code needed in a Relying Party, in 302 order to both minimize footprint and to minimize the attack surface 303 area. So while it would be possible to embed a CWT inside a JWT, or 304 a JWT inside an X.509 extension, etc., there is a desire to encode 305 the information natively in the format that is natural for the 306 Relying Party. 308 This motivates having a common "information model" that describes the 309 set of attestation related information in an encoding-agnostic way, 310 and allowing multiple serialization formats (CWT, JWT, X.509, etc.) 311 that encode the same information into the format needed by the 312 Relying Party. 314 5. Architectural Models 316 There are multiple possible models for communication between an 317 Attester, a Verifier, and a Relying Party. 319 5.1. Passport Model 321 In this model, an Attester sends Evidence to a Verifier, which 322 compares the Evidence against its security policy. The Verifier then 323 gives back an Attestation Result. If the Attestation Result was a 324 successful one, the Attester can then present the Attestation Result 325 to a Relying Party, which then compares the Attestation Result 326 against its own security policy. 328 Since the resource access protocol between the Attester and Relying 329 Party includes an Attestation Result, in this model the details of 330 that protocol constrain the serialization format of the Attestation 331 Result. The format of the Evidence on the other hand is only 332 constrained by the Attester-Verifier attestation protocol. 334 +-------------+ 335 | | Compare Evidence 336 | Verifier | against security policy 337 | | 338 +-------------+ 339 ^ | 340 Evidence| |Attestation 341 | | Result 342 | v 343 +-------------+ +-------------+ 344 | |-------------->| | Compare Attestation 345 | Attester | Attestation | Relying | Result against 346 | | Result | Party | security policy 347 +-------------+ +-------------+ 349 Figure 2: Passport Model 351 The passport model is so named because it resembles the process 352 typically used for passports and drivers licenses, where a person 353 applies and gets a passport or license that is issued by a government 354 and shows information such as the person's name and birthdate. The 355 passport or license can then be supplied to other entities to gain 356 entrance to an airport boarding area, or age-restricted section of a 357 bar, where the passport or license is considered sufficient because 358 it vouches for that piece of information and is issued by a trusted 359 authority. Thus, in this analogy, the passport issuing agency is a 360 Verifier, the passport is an Attestation Result, and the airport 361 security is a Relying Party. 363 5.2. Background-Check Model 365 In this model, an Attester sends Evidence to a Relying Party, which 366 simply passes it on to a Verifier. The Verifier then compares the 367 Evidence against its security policy, and returns an Attestation 368 Result to the Relying Party. The Relying Party then compares the 369 Attestation Result against its own security policy. 371 The resource access protocol between the Attester and Relying Party 372 includes Evidence rather than an Attestation Result, but that 373 Evidence is not processed by the Relying Party. Since the Evidence 374 is merely forwarded on to a trusted Verifier, any serialization 375 format can be used for Evidence because the Relying Party does not 376 need a parser for it. The only requirement is that the Evidence can 377 be _encapsulated in_ the format required by the resource access 378 protocol between the Attester and Relying Party. 380 However, like in the Passport model, an Attestation Result is still 381 consumed by the Relying Party and so the serialization format of the 382 Attestation Result is still important. If the Relying Party is a 383 constrained node whose purpose is to serve a given type resource 384 using a standard resource access protocol, it already needs the 385 parser(s) required by that existing protocol. Hence, the ability to 386 let the Relying Party obtain an Attestation Result in the same 387 serialization format allows minimizing the code footprint and attack 388 surface area of the Relying Party, especially if the Relying Party is 389 a constrained node. 391 +-------------+ 392 | | Compare Evidence 393 | Verifier | against security policy 394 | | 395 +-------------+ 396 ^ | 397 Evidence| |Attestation 398 | | Result 399 | v 400 +-------------+ +-------------+ 401 | |-------------->| | Compare Attestation 402 | Attester | Evidence | Relying | Result against 403 | | | Party | security policy 404 +-------------+ +-------------+ 406 Figure 3: Background-Check Model 408 The background-check model is so named because it resembles the 409 process typically used for job and loan applications, where a person 410 fills out an application to get a job or a loan from a company, and 411 the company then does a background check with some other agency that 412 checks credit history, arrest records, etc. and gives back a report 413 on the application that is then used to help determine whether to 414 actually offer the job or loan. Thus, in this analogy, a person 415 asking for a loan is an Attester, the bank is the Relying Party, and 416 a credit report agency is a Verifier. 418 5.3. Combinations 420 A variation of the background-check model is a "Verifying Relying 421 party", where the Relying Party and the Verifier on the same machine, 422 and so there is no need for a protocol between the two. 424 It is also worth pointing out that the choice of model is generally 425 up to the relying party, and the same device may need to attest to 426 different relying parties for different use cases (e.g., a network 427 infrastructure device to gain access to the network, and then a 428 server holding confidential data to get access to that data). As 429 such, both models may simultaneously be in use by the same device. 431 Figure 4 shows another example of a combination where Relying Party 1 432 uses the passport model, whereas Relying Party 2 uses an extension of 433 the background-check model. Specifically, in addition to the basic 434 functionality shown in Figure 3, Relying Party 2 actually provides 435 the Attestation Result back to the Attester, allowing the Attester to 436 use it with other Relying Parties. This is the model that the 437 Trusted Application Manager plans to support in the TEEP architecture 438 [I-D.ietf-teep-architecture]. 440 +-------------+ 441 | | Compare Evidence 442 | Verifier | against security policy 443 | | 444 +-------------+ 445 ^ | 446 Evidence| |Attestation 447 | | Result 448 | v 449 +-------------+ 450 | | Compare 451 | Relying | Attestation Result 452 | Party 2 | against security policy 453 +-------------+ 454 ^ | 455 Evidence| |Attestation 456 | | Result 457 | v 458 +-------------+ +-------------+ 459 | |-------------->| | Compare Attestation 460 | Attester | Attestation | Relying | Result against 461 | | Result | Party 1 | security policy 462 +-------------+ +-------------+ 464 Figure 4: Example Combination 466 6. Trust Model 468 The scope of this document is scenarios for which a Relying Party 469 trusts a Verifier that can evaluate the trustworthiness of 470 information about an Attester. Such trust might come by the Relying 471 Party trusting the Verifier (or its public key) directly, or might 472 come by trusting an entity (e.g., a Certificate Authority) that the 473 Verifier has a certificate that chains up to. The Relying Party 474 might implicitly trust a Verifier (such as in the Verifying Relying 475 Party combination). Or, for a stronger level of security, the 476 Relying Party might require that the Verifier itself provide 477 information about itself that the Relying Party can use to evaluate 478 the health of the Verifier before accepting its Attestation Results. 480 In solutions following the background-check model, the Attester is 481 assumed to trust the Verifier (again, whether directly or indirectly 482 via a Certificate Authority that it trusts), since the Attester 483 relies on an Attestation Result it obtains from the Verifier, in 484 order to access resources. 486 The Verifier trusts (or more specifically, the Verifier's security 487 policy is written in a way that configures the Verifier to trust) a 488 manufacturer, or the manufacturer's hardware, so as to be able to 489 evaluate the health of that manufacturer's devices. In solutions 490 with weaker security, a Verifier might be configured to implicitly 491 trust firmware or even software (e.g., a hypervisor). That is, it 492 might evaluate the health of an application component, or operating 493 system component or service, under the assumption that information 494 provided about it by the lower-layer hypervisor or firmware is true. 495 A stronger level of security comes when information can be vouched 496 for by hardware or by ROM code, especially if such hardware is 497 physically resistant to hardware tampering. The component that is 498 implicitly trusted is often referred to as a Root of Trust. 500 7. Conceptual Messages 502 7.1. Evidence 504 Today, Evidence tends to be highly device-specific, since the 505 information in the evidence often includes vendor-specific 506 information that is necessary to fully describe the manufacturer and 507 model of the device including its security properties, the health of 508 the device, and the level of confidence in the correctness of the 509 information. Evidence is typically signed by the device (whether by 510 hardware, firmware, or software on the device), and evaluating it in 511 isolation would require security policy to be based on device- 512 specific details (e.g., a device public key). 514 7.2. Endorsements 516 An Endorsement is a secure statement that a manufacturer vouches for 517 the integrity of the device's signing capability. For example, if 518 the signing capability is in hardware, then an Endorsement might be a 519 manufacturer certificate that signs a public key whose corresponding 520 private key is only known inside the device's hardware. Thus, when 521 Evidence and such an Endorsement are used together, evaluating them 522 can be done against security policy that may not be specific to the 523 device instance, but merely specific to the manufacturer providing 524 the Endorsement. For example, a security policy might simply check 525 that devices from a given manufacturer have information matching a 526 set of known-good reference values, or a security policy might have a 527 set of more complex logic on how to evaluate the validity of 528 information. 530 However, while a security policy that treats all devices from a given 531 manufacturer the same may be appropriate for some use cases, it would 532 be inappropriate to use such a security policy as the sole means of 533 authorization for use cases that wish to constrain _which_ compliant 534 devices are considered authorized for some purpose. For example, an 535 enterprise using attestation for Network Endpoint Assessment may not 536 wish to let every healthy laptop from the same manufacturer onto the 537 network, but instead only want to let devices that it legally owns 538 onto the network. Thus, an Endorsement may be helpful information in 539 authenticating information about a device, but is not necessarily 540 sufficient to authorize access to resources which may need device- 541 specific information such as a public key for the device or component 542 or user on the device. 544 7.3. Attestation Results 546 Attestation Results may indicate compliance or non-compliance with a 547 Verifier's security policy. A result that indicates non-compliance 548 can be used by an Attester (in the passport model) or a Relying Party 549 (in the background-check model) to indicate that the Attester should 550 not be treated as authorized and may be in need of remediation. In 551 some cases, it may even indicate that the Evidence itself cannot be 552 authenticated as being correct. 554 An Attestation Result that indicates compliance can be used by a 555 Relying Party to make authorization decisions based on the Relying 556 Party's security policy. The simplest such policy might be to simply 557 authorize any party supplying a compliant Attestation Result signed 558 by a trusted Verifier. A more complex policy might also entail 559 comparing information provided in the result against known-good 560 reference values, or applying more complex logic using such 561 information. 563 Thus, Attestation Results often need to include detailed information 564 about the Attester, for use by Relying Parties, much like physical 565 passports and drivers licenses include personal information such as 566 name and date of birth. Unlike Evidence, which is often very device- 567 and vendor-specific, Attestation Results can be vendor-neutral if the 568 Verifier has a way to generate vendor-agnostic information based on 569 evaluating vendor-specific information in Evidence. This allows a 570 Relying Party's security policy to be simpler, potentially based on 571 standard ways of expressing the information, while still allowing 572 interoperability with heterogeneous devices. 574 Finally, whereas Evidence is signed by the device (or indirectly by a 575 manufacturer, if Endorsements are used), Attestation Results are 576 signed by a Verifier, allowing a Relying Party to only need a trust 577 relationship with one entity, rather than a larger set of entities, 578 for purposes of its security policy. 580 8. Security Considerations 582 To evaluate the security provided by a particular security policy, it 583 is important to understand the strength of the Root of Trust, e.g., 584 whether it is mutable software, or firmware that is read-only after 585 boot, or immutable hardware/ROM. 587 It is also important that the security policy was itself obtained 588 securely. As such, if security policy in a Relying Party or Verifier 589 can be configured via a network protocol, the ability to attest to 590 the health of the client providing the security policy needs to be 591 considered. 593 9. IANA Considerations 595 This document does not require any actions by IANA. 597 10. Acknowledgements 599 Some content in this document came from drafts by Michael Richardson, 600 Henk Birkholz, and Ned Smith, and from the IETF RATS Working Group 601 Charter. 603 11. Informative References 605 [I-D.ietf-teep-architecture] 606 Pei, M., Tschofenig, H., Wheeler, D., Atyeo, A., and D. 607 Liu, "Trusted Execution Environment Provisioning (TEEP) 608 Architecture", draft-ietf-teep-architecture-03 (work in 609 progress), July 2019. 611 [OPCUA] OPC Foundation, "OPC Unified Architecture Specification, 612 Part 2: Security Model, Release 1.03", Global 613 Platform GPD_SPE_009, November 2015, 614 . 617 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 618 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 619 . 621 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 622 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 623 . 625 [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, 626 "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, 627 May 2018, . 629 Author's Address 631 Dave Thaler 632 Microsoft 634 EMail: dthaler@microsoft.com