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