From 5b3f155502d25a0e7a85e14778b8df1e77e8bcfd Mon Sep 17 00:00:00 2001 From: ID Bot Date: Wed, 2 Oct 2024 08:12:54 +0000 Subject: [PATCH] Script updating gh-pages from 9c990a9. [ci skip] --- draft-ietf-oauth-status-list.html | 254 ++++++++++++++++++++++-------- draft-ietf-oauth-status-list.txt | 210 ++++++++++++++++++------ 2 files changed, 353 insertions(+), 111 deletions(-) diff --git a/draft-ietf-oauth-status-list.html b/draft-ietf-oauth-status-list.html index 3e976f3..47968ec 100644 --- a/draft-ietf-oauth-status-list.html +++ b/draft-ietf-oauth-status-list.html @@ -1026,11 +1026,11 @@ Internet-Draft Token Status List -September 2024 +October 2024 Looker, et al. -Expires 28 March 2025 +Expires 5 April 2025 [Page] @@ -1043,12 +1043,12 @@
draft-ietf-oauth-status-list-latest
Published:
- +
Intended Status:
Informational
Expires:
-
+
Authors:
@@ -1101,7 +1101,7 @@

time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

- This Internet-Draft will expire on 28 March 2025.

+ This Internet-Draft will expire on 5 April 2025.

The following is the CBOR Annotated Hex output of the example above:

@@ -1763,12 +1760,12 @@

6269747301636c73744a78da # "bits\x01clstJxÚ" dbb918000217015d # "Û¹\x18\x00\x02\x17\x01]" 58 40 # bytes(64) - 8bc8b1a6387862e4f94402c7 # "\x8bȱ¦8xbäùD\x02Ç" - d77f417fd4902ef71df8bdff # "×\x7fA\x7fÔ\x90.÷\x1dø½ÿ" - c688f421b7f9b605ca25d537 # "Æ\x88ô!·ù¶\x05Ê%Õ7" - c3bb2bdec5307840e99e2bcd # "û+ÞÅ0x@é\x9e+Í" - 2b708e52c331a32d0e41fc42 # "+p\x8eRÃ1£-\x0eAüB" - 6487bf51 # "d\x87¿Q" + 5adbc2423e2ed9260f904a43 # "ZÛÂB>.Ù&\x0f\x90JC" + d51bad80b5bd78e00640d641 # "Õ\x1b\xad\x80µ½xà\x06@ÖA" + e566f12b362781e0de78737c # "åfñ+6'\x81àÞxs|" + 8c973ff2aec721ae878e3b3d # "\x8c\x97?ò®Ç!®\x87\x8e;=" + 8a9a1d2f3b0846db45b2f1ea # "\x8a\x9a\x1d/;\x08FÛE²ñê" + 81fd1383 # "\x81ý\x13\x83" @@ -1788,10 +1785,10 @@

By including a "status" claim in a Referenced Token, the Issuer is referencing a mechanism to retrieve status information about this Referenced Token. The claim contains members used to reference to a status list as defined in this specification. Other members of the "status" object may be defined by other specifications. This is analogous to "cnf" claim in Section 3.1 of [RFC7800] in which different authenticity confirmation methods can be included.

-
+
-

-6.2. Referenced Token in JOSE Format +

+6.2. Referenced Token in JOSE

The Referenced Token MAY be encoded as a "JSON Web Token (JWT)" according to [RFC7519] or other formats based on JOSE.

The following content applies to the JWT Claims Set:

@@ -1832,7 +1829,7 @@

}

-

SD-JWT-based Verifiable Credentials [SD-JWT.VC] introduce the usage of Status List in Section 3.2.2.2. The "status" object uses the same encoding as a JWT as defined in Section 6.2.

+

SD-JWT-based Verifiable Credentials [SD-JWT.VC] introduce the usage of Status List in Section 3.2.2.2. The "status" object uses the same encoding as a JWT as defined in Section 6.2.

The following is a non-normative example for a Referenced Token in SD-JWT-VC serialized form as received from an Issuer:

@@ -1878,25 +1875,25 @@
-
+
-

-6.3. Referenced Token in CWT Format +

+6.3. Referenced Token in COSE

-

The Referenced Token MUST be encoded as a "COSE Web Token (CWT)" object according to [RFC8392].

+

The Referenced Token MAY be encoded as a "COSE Web Token (CWT)" object according to [RFC8392] or other formats based on COSE.

The following content applies to the CWT Claims Set:

  • 65535 (status): REQUIRED. The status claim is encoded as a Status CBOR structure and MUST include at least one data item that refers to a status mechanism. Each data item in the Status CBOR structure comprises a key-value pair, where the key must be a CBOR text string (Major Type 3) specifying the identifier of the status mechanism, and the corresponding value defines its contents. This specification defines the following data items:

    • -

      status_list (status list): REQUIRED when the status list mechanism defined in this specification is used. It has the same definition as the status_list claim in Section 6.2 but MUST be encoded as a StatusListInfo CBOR structure with the following fields:

      +

      status_list (status list): REQUIRED when the status list mechanism defined in this specification is used. It has the same definition as the status_list claim in Section 6.2 but MUST be encoded as a StatusListInfo CBOR structure with the following fields:

      • @@ -1910,9 +1907,9 @@

      d28443a10126a1044231325866a502653132333435017368747470733a2f2f657861 6d706c652e636f6d061a648c5bea041a8898dfea19ffffa16b7374617475735f6c69 7374a2636964780063757269782168747470733a2f2f6578616d706c652e636f6d2f -7374617475736c697374732f3158402c55f1252a58679d3d9cff68776f25fd4c8e19 -f860843e3820d6ed1a8692bea950dbdcc75508a40d4629371e5c5ddf481263dce8d0 -202eb54ad3d2d9e7a51c23 +7374617475736c697374732f3158409bca2828ffc3b0aeeea05e99ee4089d7d580ae +f69f0a4b798bc2337a60dd21182aa9d7d938671468ea5596ddc4737ac9cdc2a4c00e +a421f19710a58dd99ae10a

The following is the CBOR Annotated Hex output of the example above:

@@ -1937,27 +1934,148 @@

2e636f6d2f7374617475736c # ".com/statusl" 697374732f31 # "ists/1" 58 40 # bytes(64) - 2c55f1252a58679d3d9cff68 # ",Uñ%*Xg\x9d=\x9cÿh" - 776f25fd4c8e19f860843e38 # "wo%ýL\x8e\x19ø`\x84>8" - 20d6ed1a8692bea950dbdcc7 # " Öí\x1a\x86\x92¾©PÛÜÇ" - 5508a40d4629371e5c5ddf48 # "U\x08¤\x0dF)7\x1e\]ßH" - 1263dce8d0202eb54ad3d2d9 # "\x12cÜèÐ .µJÓÒÙ" - e7a51c23 # "ç¥\x1c#" + 9bca2828ffc3b0aeeea05e99 # "\x9bÊ((ÿð®î\xa0^\x99" + ee4089d7d580aef69f0a4b79 # "î@\x89×Õ\x80®ö\x9f\x0aKy" + 8bc2337a60dd21182aa9d7d9 # "\x8bÂ3z`Ý!\x18*©×Ù" + 38671468ea5596ddc4737ac9 # "8g\x14hêU\x96ÝÄszÉ" + cdc2a4c00ea421f19710a58d # "ͤÀ\x0e¤!ñ\x97\x10¥\x8d" + d99ae10a # "Ù\x9aá\x0a"

- +

ISO mdoc [ISO.mdoc] may utilize the Status List mechanism by introducing the status parameter in the Mobile Security Object (MSO) as specified in Section 9.1.2. The status parameter uses the same encoding as a CWT as defined in Section 6.3.

+

It is RECOMMENDED to use status for the label of the field that contains the Status CBOR structure.

+

Application of additional restrictions and policy are at the discretion of the verifying party.

+

The following is a non-normative example for an IssuerAuth as specified in ISO mDL (also referred to as signed MSO) in Hex:

+
+
+8443a10126a118215901f3308201ef30820195a00302010202140bfec7da97e048e
+15ac3dacb9eafe82e64fd07f5300a06082a8648ce3d040302302331143012060355
+04030c0b75746f7069612069616361310b3009060355040613025553301e170d323
+4313030313030303030305a170d3235313030313030303030305a30213112301006
+035504030c0975746f706961206473310b300906035504061302555330593013060
+72a8648ce3d020106082a8648ce3d03010703420004ace7ab7340e5d9648c5a72a9
+a6f56745c7aad436a03a43efea77b5fa7b88f0197d57d8983e1b37d3a539f4d5883
+65e38cbbf5b94d68c547b5bc8731dcd2f146ba381a83081a5301c0603551d1f0415
+30133011a00fa00d820b6578616d706c652e636f6d301e0603551d1204173015811
+36578616d706c65406578616d706c652e636f6d301d0603551d0e0416041414e290
+17a6c35621ffc7a686b7b72db06cd12351301f0603551d2304183016801454fa238
+3a04c28e0d930792261c80c4881d2c00b300e0603551d0f0101ff04040302078030
+150603551d250101ff040b3009060728818c5d050102300a06082a8648ce3d04030
+20348003045022100b7103fd4b90529f50bd6f70c5ae5ce7f4f3d4d15a4e082812f
+9fa1f5c2e5aa0a0220070b2822ec7ce6c56804923a85b2cfbffd054cf9a915f070c
+fef7179a4bc6569590320d81859031ba766737461747573a16b7374617475735f6c
+697374a26369647819019c63757269782168747470733a2f2f6578616d706c652e6
+36f6d2f7374617475736c697374732f3167646f6354797065756f72672e69736f2e
+31383031332e352e312e6d444c6776657273696f6e63312e306c76616c696469747
+9496e666fa3667369676e6564c074323032342d31302d30315431333a33303a3032
+5a6976616c696446726f6dc074323032342d31302d30315431333a33303a30325a6
+a76616c6964556e74696cc074323032352d31302d30315431333a33303a30325a6c
+76616c756544696765737473a1716f72672e69736f2e31383031332e352e31ac005
+820a81d65ed5075fbd7ee19fa66e2bb3047ed826e2769873e7ef07c923da7a6f243
+01582048701a9546492284d266ed81d439230a582d0e1f17a08ab1859a3efe98069
+0a4025820d11fe48c8835b30bfb3895c3905436ddfb63f59ab9eee181b110985329
+2a8f62035820a741bf05e20a8bc359e32426106ed0899b2c60262cc3acc637ddc99
+41095fb7a045820ab67cb9a8f20a8572f77f02727367d08dc8e57fb89deb46b9c62
+6e94457b7d8b055820bacddb4142b3842bd555206eb5acb27ded063294995c7e7fe
+fbf93ece522604d065820bfd02b3aebdc05b53b5539226c38088d6d784b0ea0fab6
+9eb9311650a48d325307582027dab70fe71da63e5e5d199e8ae5b79cbe8904bc30c
+5b7544fb809e02ccb3e6a0858200dbd7ccc9c7727d3d17295f1b6f1914071670ee2
+3d4d33530c31f1f406b8e3b7095820a5beb5efadf37f21637209abc519830681cc5
+1f334818a823fec13b29552f5ba0a5820d8047c95f9272d7d07b2c13a9f5ac2ee02
+380ab272a165e569391d89a2152c3c0b582004939930ffb4911ef03487a153605a3
+0368b69f2437d6d21b4c90f92bc144c3e6d6465766963654b6579496e666fa16964
+65766963654b6579a40102200121582096313d6c63e24e3372742bfdb1a33ba2c89
+7dcd68ab8c753e4fbd48dca6b7f9a2258201fb3269edd418857de1b39a4e4a44b92
+fa484caa722c228288f01d0c03a2c3d66f646967657374416c676f726974686d675
+348412d3235365840b7c2d4abe85aa5ba814ef95de0385c71c802be8ac33a4a971a
+85ed800ba7acb59cb21035f4a68fc0caa450cbefd3b255aec72f83595f0ae7b7d50
+fe8a1c4cafe
+
+
+

The following is the CBOR Diagnostic Notation of the example above:

+
+
+[
+  << {
+    1: -7
+  } >>,
+  {
+    33: h'308201ef30820195a00302010202140bfec7da97e048e15ac3dacb9ea
+    fe82e64fd07f5300a06082a8648ce3d04030230233114301206035504030c0b
+    75746f7069612069616361310b3009060355040613025553301e170d3234313
+    030313030303030305a170d3235313030313030303030305a30213112301006
+    035504030c0975746f706961206473310b30090603550406130255533059301
+    306072a8648ce3d020106082a8648ce3d03010703420004ace7ab7340e5d964
+    8c5a72a9a6f56745c7aad436a03a43efea77b5fa7b88f0197d57d8983e1b37d
+    3a539f4d588365e38cbbf5b94d68c547b5bc8731dcd2f146ba381a83081a530
+    1c0603551d1f041530133011a00fa00d820b6578616d706c652e636f6d301e0
+    603551d120417301581136578616d706c65406578616d706c652e636f6d301d
+    0603551d0e0416041414e29017a6c35621ffc7a686b7b72db06cd12351301f0
+    603551d2304183016801454fa2383a04c28e0d930792261c80c4881d2c00b30
+    0e0603551d0f0101ff04040302078030150603551d250101ff040b300906072
+    8818c5d050102300a06082a8648ce3d0403020348003045022100b7103fd4b9
+    0529f50bd6f70c5ae5ce7f4f3d4d15a4e082812f9fa1f5c2e5aa0a0220070b2
+    822ec7ce6c56804923a85b2cfbffd054cf9a915f070cfef7179a4bc6569'
+  },
+  << 24( << {
+    "status": {
+      "status_list": {
+        "idx": 412,
+        "uri": "https://example.com/statuslists/1"
+      }
+    },
+    "docType": "org.iso.18013.5.1.mDL",
+    "version": "1.0",
+    "validityInfo": {
+      "signed": 2024-10-01 13:30:02+00:00,
+      "validFrom": 2024-10-01 13:30:02+00:00,
+      "validUntil": 2025-10-01 13:30:02+00:00
+    },
+    "valueDigests": {
+      "org.iso.18013.5.1": {
+        0: h'a81d65ed5075fbd7ee19fa66e2bb3047ed826e2769873e7ef07c92
+        3da7a6f243',
+        1: h'48701a9546492284d266ed81d439230a582d0e1f17a08ab1859a3e
+        fe980690a4',
+        2: h'd11fe48c8835b30bfb3895c3905436ddfb63f59ab9eee181b11098
+        53292a8f62',
+        3: h'a741bf05e20a8bc359e32426106ed0899b2c60262cc3acc637ddc9
+        941095fb7a',
+        4: h'ab67cb9a8f20a8572f77f02727367d08dc8e57fb89deb46b9c626e
+        94457b7d8b',
+        5: h'bacddb4142b3842bd555206eb5acb27ded063294995c7e7fefbf93
+        ece522604d',
+        6: h'bfd02b3aebdc05b53b5539226c38088d6d784b0ea0fab69eb93116
+        50a48d3253',
+        7: h'27dab70fe71da63e5e5d199e8ae5b79cbe8904bc30c5b7544fb809
+        e02ccb3e6a',
+        8: h'0dbd7ccc9c7727d3d17295f1b6f1914071670ee23d4d33530c31f1
+        f406b8e3b7',
+        9: h'a5beb5efadf37f21637209abc519830681cc51f334818a823fec13
+        b29552f5ba',
+        10: h'd8047c95f9272d7d07b2c13a9f5ac2ee02380ab272a165e569391
+        d89a2152c3c',
+        11: h'04939930ffb4911ef03487a153605a30368b69f2437d6d21b4c90
+        f92bc144c3e'
+      }
+    },
+    "deviceKeyInfo": {
+      "deviceKey": {
+        1: 2,
+        -1: 1,
+        -2: h'96313d6c63e24e3372742bfdb1a33ba2c897dcd68ab8c753e4fbd
+        48dca6b7f9a',
+        -3: h'1fb3269edd418857de1b39a4e4a44b92fa484caa722c228288f01
+        d0c03a2c3d6'
+      }
+    },
+    "digestAlgorithm": "SHA-256"
+  } >> ) >>,
+  h'b7c2d4abe85aa5ba814ef95de0385c71c802be8ac33a4a971a85ed800ba7acb
+  59cb21035f4a68fc0caa450cbefd3b255aec72f83595f0ae7b7d50fe8a1c4cafe'
+]
+
-
-
-

-6.4. Referenced Token in other COSE/CBOR Format -

-

The Referenced Token MUST be encoded as a COSE_Sign1 or COSE_Sign CBOR structure as defined in "CBOR Object Signing and Encryption (COSE)" [RFC9052].

-

It is required to encode the status mechanisms referred to in the Referenced Token using the Status CBOR structure defined in Section 6.3.

-

It is RECOMMENDED to use status for the label of the field that contains the Status CBOR structure.

-

Application of additional restrictions and policy are at the discretion of the verifying party.

-

The following is a non-normative example for a decoded payload of a Referenced Token:

-

TBD: example

@@ -2062,7 +2180,7 @@

If this validation was not successful, the Referenced Token MUST be rejected. If the validation was successful, the Relying Party MUST perform the following validation steps to evaluate the status of the reference token:

  1. -

    Check for the existence of a status claim, check for the existence of a status_list claim within the status claim and validate that the content of status_list adheres to the rules defined in Section 6.2 for JWTs and Section 6.3 for CWTs. This step can be overruled if defined within the Referenced Token Format natively

    +

    Check for the existence of a status claim, check for the existence of a status_list claim within the status claim and validate that the content of status_list adheres to the rules defined in Section 6.2 for JWTs and Section 6.3 for CWTs. This step can be overruled if defined within the Referenced Token Format natively

  2. Resolve the Status List from the provided URI

    @@ -2501,7 +2619,7 @@

    Change Controller: IETF

  3. -

    Specification Document(s): Section 6.2 of this specification

    +

    Specification Document(s): Section 6.2 of this specification

    4. @@ -2631,7 +2749,7 @@

    Change Controller: IETF

  4. -

    Specification Document(s): Section 6.3 of this specification

    +

    Specification Document(s): Section 6.3 of this specification

    5. @@ -3015,6 +3133,7 @@

    Guiseppe De Marco, Kristina Yasuda, Markus Kreusch, +Martijn Haring, Michael B. Jones, Mike Prorock, Oliver Terbu, @@ -3033,40 +3152,43 @@

    -04

    • -

      add implementation consideration for Default Values, Double Allocation and Status List Size

      +

      add mDL example as Referenced Token and consolidate CWT and CBOR sections

    • -

      add privacy consideration on using private relay protocols

      +

      add implementation consideration for Default Values, Double Allocation and Status List Size

    • -

      add privacy consideration on observability of outsiders

      +

      add privacy consideration on using private relay protocols

    • -

      add security considerations on correct parsing and decoding

      +

      add privacy consideration on observability of outsiders

    • -

      remove requirement for matching iss claim in Referenced Token and Status List Token

      +

      add security considerations on correct parsing and decoding

    • -

      add sd-jwt-vc example

      +

      remove requirement for matching iss claim in Referenced Token and Status List Token

    • -

      fix CWT status_list map encoding

      +

      add sd-jwt-vc example

    • -

      editorial fixes

      +

      fix CWT status_list map encoding

    • -

      add CORS considerations to the http endpoint

      +

      editorial fixes

    • -

      fix reference of Status List in CBOR format

      +

      add CORS considerations to the http endpoint

    • -

      added status_list CWT claim key assigned

      +

      fix reference of Status List in CBOR format

    • -

      move base64url definition to terminology

      +

      added status_list CWT claim key assigned

      +
      • +
    • +

      move base64url definition to terminology

    -03

    diff --git a/draft-ietf-oauth-status-list.txt b/draft-ietf-oauth-status-list.txt index d11338f..c1882d5 100644 --- a/draft-ietf-oauth-status-list.txt +++ b/draft-ietf-oauth-status-list.txt @@ -5,10 +5,10 @@ Network Working Group T. Looker Internet-Draft MATTR Intended status: Informational P. Bastian -Expires: 28 March 2025 +Expires: 5 April 2025 C. Bormann Robert Bosch GmbH - 24 September 2024 + 2 October 2024 Token Status List @@ -50,7 +50,7 @@ Status of This Memo time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on 28 March 2025. + This Internet-Draft will expire on 5 April 2025. Copyright Notice @@ -81,9 +81,8 @@ Table of Contents 5.2. Status List Token in CWT Format 6. Referenced Token 6.1. Status Claim - 6.2. Referenced Token in JOSE Format - 6.3. Referenced Token in CWT Format - 6.4. Referenced Token in other COSE/CBOR Format + 6.2. Referenced Token in JOSE + 6.3. Referenced Token in COSE 7. Status Types 7.1. Status Types Values 8. Verification and Processing @@ -526,9 +525,9 @@ Table of Contents d28453a20126106e7374617475736c6973742b637774a1044231325850a502782168 747470733a2f2f6578616d706c652e636f6d2f7374617475736c697374732f31061a 648c5bea041a8898dfea19fffe19a8c019fffda2646269747301636c73744a78dadb - b918000217015d58408bc8b1a6387862e4f94402c7d77f417fd4902ef71df8bdffc6 - 88f421b7f9b605ca25d537c3bb2bdec5307840e99e2bcd2b708e52c331a32d0e41fc - 426487bf51 + b918000217015d58405adbc2423e2ed9260f904a43d51bad80b5bd78e00640d641e5 + 66f12b362781e0de78737c8c973ff2aec721ae878e3b3d8a9a1d2f3b0846db45b2f1 + ea81fd1383 The following is the CBOR Annotated Hex output of the example above: @@ -550,12 +549,12 @@ d2 # tag(18) 6269747301636c73744a78da # "bits\x01clstJxÚ" dbb918000217015d # "Û¹\x18\x00\x02\x17\x01]" 58 40 # bytes(64) - 8bc8b1a6387862e4f94402c7 # "\x8bȱ¦8xbäùD\x02Ç" - d77f417fd4902ef71df8bdff # "×\x7fA\x7fÔ\x90.÷\x1dø½ÿ" - c688f421b7f9b605ca25d537 # "Æ\x88ô!·ù¶\x05Ê%Õ7" - c3bb2bdec5307840e99e2bcd # "û+ÞÅ0x@é\x9e+Í" - 2b708e52c331a32d0e41fc42 # "+p\x8eRÃ1£-\x0eAüB" - 6487bf51 # "d\x87¿Q" + 5adbc2423e2ed9260f904a43 # "ZÛÂB>.Ù&\x0f\x90JC" + d51bad80b5bd78e00640d641 # "Õ\x1b\xad\x80µ½xà\x06@ÖA" + e566f12b362781e0de78737c # "åfñ+6'\x81àÞxs|" + 8c973ff2aec721ae878e3b3d # "\x8c\x97?ò®Ç!®\x87\x8e;=" + 8a9a1d2f3b0846db45b2f1ea # "\x8a\x9a\x1d/;\x08FÛE²ñê" + 81fd1383 # "\x81ý\x13\x83" 6. Referenced Token @@ -569,7 +568,7 @@ d2 # tag(18) analogous to "cnf" claim in Section 3.1 of [RFC7800] in which different authenticity confirmation methods can be included. -6.2. Referenced Token in JOSE Format +6.2. Referenced Token in JOSE The Referenced Token MAY be encoded as a "JSON Web Token (JWT)" according to [RFC7519] or other formats based on JOSE. @@ -659,10 +658,10 @@ d2 # tag(18) "_sd_alg": "sha-256" } -6.3. Referenced Token in CWT Format +6.3. Referenced Token in COSE - The Referenced Token MUST be encoded as a "COSE Web Token (CWT)" - object according to [RFC8392]. + The Referenced Token MAY be encoded as a "COSE Web Token (CWT)" + object according to [RFC8392] or other formats based on COSE. The following content applies to the CWT Claims Set: @@ -693,9 +692,9 @@ d2 # tag(18) d28443a10126a1044231325866a502653132333435017368747470733a2f2f657861 6d706c652e636f6d061a648c5bea041a8898dfea19ffffa16b7374617475735f6c69 7374a2636964780063757269782168747470733a2f2f6578616d706c652e636f6d2f - 7374617475736c697374732f3158402c55f1252a58679d3d9cff68776f25fd4c8e19 - f860843e3820d6ed1a8692bea950dbdcc75508a40d4629371e5c5ddf481263dce8d0 - 202eb54ad3d2d9e7a51c23 + 7374617475736c697374732f3158409bca2828ffc3b0aeeea05e99ee4089d7d580ae + f69f0a4b798bc2337a60dd21182aa9d7d938671468ea5596ddc4737ac9cdc2a4c00e + a421f19710a58dd99ae10a The following is the CBOR Annotated Hex output of the example above: @@ -718,22 +717,17 @@ d2 # tag(18) 2e636f6d2f7374617475736c # ".com/statusl" 697374732f31 # "ists/1" 58 40 # bytes(64) - 2c55f1252a58679d3d9cff68 # ",Uñ%*Xg\x9d=\x9cÿh" - 776f25fd4c8e19f860843e38 # "wo%ýL\x8e\x19ø`\x84>8" - 20d6ed1a8692bea950dbdcc7 # " Öí\x1a\x86\x92¾©PÛÜÇ" - 5508a40d4629371e5c5ddf48 # "U\x08¤\x0dF)7\x1e\]ßH" - 1263dce8d0202eb54ad3d2d9 # "\x12cÜèÐ .µJÓÒÙ" - e7a51c23 # "ç¥\x1c#" - -6.4. Referenced Token in other COSE/CBOR Format - - The Referenced Token MUST be encoded as a COSE_Sign1 or COSE_Sign - CBOR structure as defined in "CBOR Object Signing and Encryption - (COSE)" [RFC9052]. - - It is required to encode the status mechanisms referred to in the - Referenced Token using the Status CBOR structure defined in - Section 6.3. + 9bca2828ffc3b0aeeea05e99 # "\x9bÊ((ÿð®î\xa0^\x99" + ee4089d7d580aef69f0a4b79 # "î@\x89×Õ\x80®ö\x9f\x0aKy" + 8bc2337a60dd21182aa9d7d9 # "\x8bÂ3z`Ý!\x18*©×Ù" + 38671468ea5596ddc4737ac9 # "8g\x14hêU\x96ÝÄszÉ" + cdc2a4c00ea421f19710a58d # "ͤÀ\x0e¤!ñ\x97\x10¥\x8d" + d99ae10a # "Ù\x9aá\x0a" + + ISO mdoc [ISO.mdoc] may utilize the Status List mechanism by + introducing the status parameter in the Mobile Security Object (MSO) + as specified in Section 9.1.2. The status parameter uses the same + encoding as a CWT as defined in Section 6.3. It is RECOMMENDED to use status for the label of the field that contains the Status CBOR structure. @@ -741,10 +735,133 @@ d2 # tag(18) Application of additional restrictions and policy are at the discretion of the verifying party. - The following is a non-normative example for a decoded payload of a - Referenced Token: - - TBD: example + The following is a non-normative example for an IssuerAuth as + specified in ISO mDL (also referred to as signed MSO) in Hex: + + 8443a10126a118215901f3308201ef30820195a00302010202140bfec7da97e048e + 15ac3dacb9eafe82e64fd07f5300a06082a8648ce3d040302302331143012060355 + 04030c0b75746f7069612069616361310b3009060355040613025553301e170d323 + 4313030313030303030305a170d3235313030313030303030305a30213112301006 + 035504030c0975746f706961206473310b300906035504061302555330593013060 + 72a8648ce3d020106082a8648ce3d03010703420004ace7ab7340e5d9648c5a72a9 + a6f56745c7aad436a03a43efea77b5fa7b88f0197d57d8983e1b37d3a539f4d5883 + 65e38cbbf5b94d68c547b5bc8731dcd2f146ba381a83081a5301c0603551d1f0415 + 30133011a00fa00d820b6578616d706c652e636f6d301e0603551d1204173015811 + 36578616d706c65406578616d706c652e636f6d301d0603551d0e0416041414e290 + 17a6c35621ffc7a686b7b72db06cd12351301f0603551d2304183016801454fa238 + 3a04c28e0d930792261c80c4881d2c00b300e0603551d0f0101ff04040302078030 + 150603551d250101ff040b3009060728818c5d050102300a06082a8648ce3d04030 + 20348003045022100b7103fd4b90529f50bd6f70c5ae5ce7f4f3d4d15a4e082812f + 9fa1f5c2e5aa0a0220070b2822ec7ce6c56804923a85b2cfbffd054cf9a915f070c + fef7179a4bc6569590320d81859031ba766737461747573a16b7374617475735f6c + 697374a26369647819019c63757269782168747470733a2f2f6578616d706c652e6 + 36f6d2f7374617475736c697374732f3167646f6354797065756f72672e69736f2e + 31383031332e352e312e6d444c6776657273696f6e63312e306c76616c696469747 + 9496e666fa3667369676e6564c074323032342d31302d30315431333a33303a3032 + 5a6976616c696446726f6dc074323032342d31302d30315431333a33303a30325a6 + a76616c6964556e74696cc074323032352d31302d30315431333a33303a30325a6c + 76616c756544696765737473a1716f72672e69736f2e31383031332e352e31ac005 + 820a81d65ed5075fbd7ee19fa66e2bb3047ed826e2769873e7ef07c923da7a6f243 + 01582048701a9546492284d266ed81d439230a582d0e1f17a08ab1859a3efe98069 + 0a4025820d11fe48c8835b30bfb3895c3905436ddfb63f59ab9eee181b110985329 + 2a8f62035820a741bf05e20a8bc359e32426106ed0899b2c60262cc3acc637ddc99 + 41095fb7a045820ab67cb9a8f20a8572f77f02727367d08dc8e57fb89deb46b9c62 + 6e94457b7d8b055820bacddb4142b3842bd555206eb5acb27ded063294995c7e7fe + fbf93ece522604d065820bfd02b3aebdc05b53b5539226c38088d6d784b0ea0fab6 + 9eb9311650a48d325307582027dab70fe71da63e5e5d199e8ae5b79cbe8904bc30c + 5b7544fb809e02ccb3e6a0858200dbd7ccc9c7727d3d17295f1b6f1914071670ee2 + 3d4d33530c31f1f406b8e3b7095820a5beb5efadf37f21637209abc519830681cc5 + 1f334818a823fec13b29552f5ba0a5820d8047c95f9272d7d07b2c13a9f5ac2ee02 + 380ab272a165e569391d89a2152c3c0b582004939930ffb4911ef03487a153605a3 + 0368b69f2437d6d21b4c90f92bc144c3e6d6465766963654b6579496e666fa16964 + 65766963654b6579a40102200121582096313d6c63e24e3372742bfdb1a33ba2c89 + 7dcd68ab8c753e4fbd48dca6b7f9a2258201fb3269edd418857de1b39a4e4a44b92 + fa484caa722c228288f01d0c03a2c3d66f646967657374416c676f726974686d675 + 348412d3235365840b7c2d4abe85aa5ba814ef95de0385c71c802be8ac33a4a971a + 85ed800ba7acb59cb21035f4a68fc0caa450cbefd3b255aec72f83595f0ae7b7d50 + fe8a1c4cafe + + The following is the CBOR Diagnostic Notation of the example above: + + [ + << { + 1: -7 + } >>, + { + 33: h'308201ef30820195a00302010202140bfec7da97e048e15ac3dacb9ea + fe82e64fd07f5300a06082a8648ce3d04030230233114301206035504030c0b + 75746f7069612069616361310b3009060355040613025553301e170d3234313 + 030313030303030305a170d3235313030313030303030305a30213112301006 + 035504030c0975746f706961206473310b30090603550406130255533059301 + 306072a8648ce3d020106082a8648ce3d03010703420004ace7ab7340e5d964 + 8c5a72a9a6f56745c7aad436a03a43efea77b5fa7b88f0197d57d8983e1b37d + 3a539f4d588365e38cbbf5b94d68c547b5bc8731dcd2f146ba381a83081a530 + 1c0603551d1f041530133011a00fa00d820b6578616d706c652e636f6d301e0 + 603551d120417301581136578616d706c65406578616d706c652e636f6d301d + 0603551d0e0416041414e29017a6c35621ffc7a686b7b72db06cd12351301f0 + 603551d2304183016801454fa2383a04c28e0d930792261c80c4881d2c00b30 + 0e0603551d0f0101ff04040302078030150603551d250101ff040b300906072 + 8818c5d050102300a06082a8648ce3d0403020348003045022100b7103fd4b9 + 0529f50bd6f70c5ae5ce7f4f3d4d15a4e082812f9fa1f5c2e5aa0a0220070b2 + 822ec7ce6c56804923a85b2cfbffd054cf9a915f070cfef7179a4bc6569' + }, + << 24( << { + "status": { + "status_list": { + "idx": 412, + "uri": "https://example.com/statuslists/1" + } + }, + "docType": "org.iso.18013.5.1.mDL", + "version": "1.0", + "validityInfo": { + "signed": 2024-10-01 13:30:02+00:00, + "validFrom": 2024-10-01 13:30:02+00:00, + "validUntil": 2025-10-01 13:30:02+00:00 + }, + "valueDigests": { + "org.iso.18013.5.1": { + 0: h'a81d65ed5075fbd7ee19fa66e2bb3047ed826e2769873e7ef07c92 + 3da7a6f243', + 1: h'48701a9546492284d266ed81d439230a582d0e1f17a08ab1859a3e + fe980690a4', + 2: h'd11fe48c8835b30bfb3895c3905436ddfb63f59ab9eee181b11098 + 53292a8f62', + 3: h'a741bf05e20a8bc359e32426106ed0899b2c60262cc3acc637ddc9 + 941095fb7a', + 4: h'ab67cb9a8f20a8572f77f02727367d08dc8e57fb89deb46b9c626e + 94457b7d8b', + 5: h'bacddb4142b3842bd555206eb5acb27ded063294995c7e7fefbf93 + ece522604d', + 6: h'bfd02b3aebdc05b53b5539226c38088d6d784b0ea0fab69eb93116 + 50a48d3253', + 7: h'27dab70fe71da63e5e5d199e8ae5b79cbe8904bc30c5b7544fb809 + e02ccb3e6a', + 8: h'0dbd7ccc9c7727d3d17295f1b6f1914071670ee23d4d33530c31f1 + f406b8e3b7', + 9: h'a5beb5efadf37f21637209abc519830681cc51f334818a823fec13 + b29552f5ba', + 10: h'd8047c95f9272d7d07b2c13a9f5ac2ee02380ab272a165e569391 + d89a2152c3c', + 11: h'04939930ffb4911ef03487a153605a30368b69f2437d6d21b4c90 + f92bc144c3e' + } + }, + "deviceKeyInfo": { + "deviceKey": { + 1: 2, + -1: 1, + -2: h'96313d6c63e24e3372742bfdb1a33ba2c897dcd68ab8c753e4fbd + 48dca6b7f9a', + -3: h'1fb3269edd418857de1b39a4e4a44b92fa484caa722c228288f01 + d0c03a2c3d6' + } + }, + "digestAlgorithm": "SHA-256" + } >> ) >>, + h'b7c2d4abe85aa5ba814ef95de0385c71c802be8ac33a4a971a85ed800ba7acb + 59cb21035f4a68fc0caa450cbefd3b255aec72f83595f0ae7b7d50fe8a1c4cafe' + ] 7. Status Types @@ -1678,9 +1795,9 @@ d2 # tag(18) Acknowledgments We would like to thank Brian Campbell, Filip Skokan, Francesco - Marino, Guiseppe De Marco, Kristina Yasuda, Markus Kreusch, Michael - B. Jones, Mike Prorock, Oliver Terbu, Orie Steele, Timo Glastra and - Torsten Lodderstedt + Marino, Guiseppe De Marco, Kristina Yasuda, Markus Kreusch, Martijn + Haring, Michael B. Jones, Mike Prorock, Oliver Terbu, Orie Steele, + Timo Glastra and Torsten Lodderstedt for their valuable contributions, discussions and feedback to this specification. @@ -1689,6 +1806,9 @@ Document History -04 + * add mDL example as Referenced Token and consolidate CWT and CBOR + sections + * add implementation consideration for Default Values, Double Allocation and Status List Size