Script updating gh-pages from ee0e8e1. [ci skip]

Author: ID Bot

222-suspended-privacy-considerations/draft-ietf-oauth-status-list.html

@@ -1312,7 +1312,7 @@ <h2 id="name-copyright-notice">
                 <p id="section-toc.1-1.12.2.7.1"><a href="#section-12.7" class="auto internal xref">12.7</a>.  <a href="#name-historical-resolution-2" class="internal xref">Historical Resolution</a></p>
 </li>
               <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.12.2.8">
-                <p id="section-toc.1-1.12.2.8.1"><a href="#section-12.8" class="auto internal xref">12.8</a>.  <a href="#name-other-status-types" class="internal xref">Other Status Types</a></p>
+                <p id="section-toc.1-1.12.2.8.1"><a href="#section-12.8" class="auto internal xref">12.8</a>.  <a href="#name-status-types-2" class="internal xref">Status Types</a></p>
 </li>
             </ul>
 </li>
@@ -1859,9 +1859,9 @@ <h3 id="name-status-list-token-in-cwt-fo">
 d28453a20126106e7374617475736c6973742b637774a1044231325850a502782168
 747470733a2f2f6578616d706c652e636f6d2f7374617475736c697374732f31061a
 648c5bea041a8898dfea19fffe19a8c019fffda2646269747301636c73744a78dadb
-b918000217015d58400926354c49b182a2e203034c50e296030e1177e8d8380be014
-bfa1c696469b2fa456e2f191ab6ed44fccf050f074e52013e2d2877fd970d8ad4b73
-8db01f942e
+b918000217015d58402135486b1e9dead0fe641f61474c950d9a727b9cb86b09ec7a
+f48cd0b1a882b3d70ae8c2a195e42ef0e26bec58f23c0b711ea6aaed8fa7c8b61c9d
+27fad1e8b0
 </pre><a href="#section-5.2-9" class="pilcrow">¶</a>
 </div>
 <p id="section-5.2-10">The following is the CBOR Annotated Hex output of the example above:<a href="#section-5.2-10" class="pilcrow">¶</a></p>
@@ -1885,12 +1885,12 @@ <h3 id="name-status-list-token-in-cwt-fo">
       6269747301636c73744a78da  #       "bits\x01clstJxÚ"
       dbb918000217015d          #       "Û¹\x18\x00\x02\x17\x01]"
     58 40                       #     bytes(64)
-      0926354c49b182a2e203034c  #       "\x09&amp;5LI±\x82¢â\x03\x03L"
-      50e296030e1177e8d8380be0  #       "Pâ\x96\x03\x0e\x11wèØ8\x0bà"
-      14bfa1c696469b2fa456e2f1  #       "\x14¿¡Æ\x96F\x9b/¤Vâñ"
-      91ab6ed44fccf050f074e520  #       "\x91«nÔOÌðPðtå "
-      13e2d2877fd970d8ad4b738d  #       "\x13âÒ\x87\x7fÙpØ\xadKs\x8d"
-      b01f942e                  #       "°\x1f\x94."
+      2135486b1e9dead0fe641f61  #       "!5Hk\x1e\x9dêÐþd\x1fa"
+      474c950d9a727b9cb86b09ec  #       "GL\x95\x0d\x9ar{\x9c¸k\x09ì"
+      7af48cd0b1a882b3d70ae8c2  #       "zô\x8cб¨\x82³×\x0aèÂ"
+      a195e42ef0e26bec58f23c0b  #       "¡\x95ä.ðâkìXò&lt;\x0b"
+      711ea6aaed8fa7c8b61c9d27  #       "q\x1e¦ªí\x8f§È¶\x1c\x9d'"
+      fad1e8b0                  #       "úÑè°"
 </pre><a href="#section-5.2-11" class="pilcrow">¶</a>
 </div>
 </section>
@@ -2032,9 +2032,9 @@ <h3 id="name-referenced-token-in-cose">
 d28443a10126a1044231325866a502653132333435017368747470733a2f2f657861
 6d706c652e636f6d061a648c5bea041a8898dfea19ffffa16b7374617475735f6c69
 7374a2636964780063757269782168747470733a2f2f6578616d706c652e636f6d2f
-7374617475736c697374732f31584080dd28f6190db96a769b6a258a6273e7e1b68d
-5cac03b144bef26e2e8cbc69a692ee32a74123b71d4f016be20a02a145a7144ca4c6
-3b9c2b33c56117f1cd32c4
+7374617475736c697374732f315840caf2aa36cc1f2e2bda113cadb8e3f001c034b2
+21146b4146553dd838517f82152ad36cba9b82b22411e05f682af0ce5738fc47955c
+0e4ca2696837273bc0f91c
 </pre><a href="#section-6.3-6" class="pilcrow">¶</a>
 </div>
 <p id="section-6.3-7">The following is the CBOR Annotated Hex output of the example above:<a href="#section-6.3-7" class="pilcrow">¶</a></p>
@@ -2059,12 +2059,12 @@ <h3 id="name-referenced-token-in-cose">
       2e636f6d2f7374617475736c  #       ".com/statusl"
       697374732f31              #       "ists/1"
     58 40                       #     bytes(64)
-      80dd28f6190db96a769b6a25  #       "\x80Ý(ö\x19\x0d¹jv\x9bj%"
-      8a6273e7e1b68d5cac03b144  #       "\x8absçá¶\x8d\¬\x03±D"
-      bef26e2e8cbc69a692ee32a7  #       "¾òn.\x8c¼i¦\x92î2§"
-      4123b71d4f016be20a02a145  #       "A#·\x1dO\x01kâ\x0a\x02¡E"
-      a7144ca4c63b9c2b33c56117  #       "§\x14L¤Æ;\x9c+3Åa\x17"
-      f1cd32c4                  #       "ñÍ2Ä"
+      caf2aa36cc1f2e2bda113cad  #       "Êòª6Ì\x1f.+Ú\x11&lt;\xad"
+      b8e3f001c034b221146b4146  #       "¸ãð\x01À4²!\x14kAF"
+      553dd838517f82152ad36cba  #       "U=Ø8Q\x7f\x82\x15*Ólº"
+      9b82b22411e05f682af0ce57  #       "\x9b\x82²$\x11à_h*ðÎW"
+      38fc47955c0e4ca269683727  #       "8üG\x95\\x0eL¢ih7'"
+      3bc0f91c                  #       ";Àù\x1c"
 </pre><a href="#section-6.3-8" class="pilcrow">¶</a>
 </div>
 <p id="section-6.3-9">ISO mdoc <span>[<a href="#ISO.mdoc" class="cite xref">ISO.mdoc</a>]</span> may utilize the Status List mechanism by introducing the <code>status</code> parameter in the Mobile Security Object (MSO) as specified in Section 9.1.2. The <code>status</code> parameter uses the same encoding as a CWT as defined in <a href="#referenced-token-cose" class="auto internal xref">Section 6.3</a>.<a href="#section-6.3-9" class="pilcrow">¶</a></p>
@@ -2231,6 +2231,7 @@ <h3 id="name-status-types-values">
         </ul>
 <p id="section-7.1-3">The Status Type value 0x03 and Status Type values in the range 0x0B until 0x0F are permanently reserved as application specific. Meaning the processing of Status Types using these values is application specific. All other Status Type values are reserved for future registration.<a href="#section-7.1-3" class="pilcrow">¶</a></p>
 <p id="section-7.1-4">The processing rules for Referenced Tokens (such as JWT or CWT) precede any evaluation of a Referenced Token's status. For example, if a token is evaluated as being expired through the "exp" (Expiration Time) but also has a status of 0x00 ("VALID"), the token is considered expired.<a href="#section-7.1-4" class="pilcrow">¶</a></p>
+<p id="section-7.1-5">See <a href="#privacy-status-types" class="auto internal xref">Section 12.8</a> for privacy considerations on status types.<a href="#section-7.1-5" class="pilcrow">¶</a></p>
 </section>
 </div>
 </section>
@@ -2276,8 +2277,8 @@ <h3 id="name-status-list-request">
 yJleHAiOjIyOTE3MjAxNzAsImlhdCI6MTY4NjkyMDE3MCwiaXNzIjoiaHR0cHM6Ly9le
 GFtcGxlLmNvbSIsInN0YXR1c19saXN0Ijp7ImJpdHMiOjEsImxzdCI6ImVOcmJ1UmdBQ
 WhjQlhRIn0sInN1YiI6Imh0dHBzOi8vZXhhbXBsZS5jb20vc3RhdHVzbGlzdHMvMSIsI
-nR0bCI6NDMyMDB9.eBXUtWOBswXG3P5Ou9vDAUU2CSRQEmTE3xSFHWnDYLfqCTDHCf4s
-0hPZ8_LxZHZWnti5TKBE5aphkf4sA99WLQ
+nR0bCI6NDMyMDB9.hY5OVb-F79wU62js971HSDBQ7PMqKi6G7vtmEOyOEDqaZTKFkQ5F
+_HwPyN3hpMWd4ocn_MXQksNAD0x5fbOPFQ
 </pre><a href="#section-8.1-10" class="pilcrow">¶</a>
 </div>
 </section>
@@ -2383,8 +2384,8 @@ <h3 id="name-historical-resolution">
 yJleHAiOjIyOTE3MjAxNzAsImlhdCI6MTY4NjkyMDE3MCwiaXNzIjoiaHR0cHM6Ly9le
 GFtcGxlLmNvbSIsInN0YXR1c19saXN0Ijp7ImJpdHMiOjEsImxzdCI6ImVOcmJ1UmdBQ
 WhjQlhRIn0sInN1YiI6Imh0dHBzOi8vZXhhbXBsZS5jb20vc3RhdHVzbGlzdHMvMSIsI
-nR0bCI6NDMyMDB9.eBXUtWOBswXG3P5Ou9vDAUU2CSRQEmTE3xSFHWnDYLfqCTDHCf4s
-0hPZ8_LxZHZWnti5TKBE5aphkf4sA99WLQ
+nR0bCI6NDMyMDB9.hY5OVb-F79wU62js971HSDBQ7PMqKi6G7vtmEOyOEDqaZTKFkQ5F
+_HwPyN3hpMWd4ocn_MXQksNAD0x5fbOPFQ
 </pre><a href="#section-8.4-7" class="pilcrow">¶</a>
 </div>
 </section>
@@ -2705,14 +2706,14 @@ <h3 id="name-historical-resolution-2">
 <p id="section-12.7-2">There are strong privacy concerns that have to be carefully taken into consideration when providing a mechanism that allows historic requests for status information - see <a href="#privacy-relying-party" class="auto internal xref">Section 12.3</a> for more details. Support for this functionality is optional and Implementers are <span class="bcp14">RECOMMENDED</span> to not support historic requests unless there are strong reasons to do so and after carefully considering the privacy implications.<a href="#section-12.7-2" class="pilcrow">¶</a></p>
 </section>
 </div>
-<div id="other-status-types">
+<div id="privacy-status-types">
 <section id="section-12.8">
-        <h3 id="name-other-status-types">
-<a href="#section-12.8" class="section-number selfRef">12.8. </a><a href="#name-other-status-types" class="section-name selfRef">Other Status Types</a>
+        <h3 id="name-status-types-2">
+<a href="#section-12.8" class="section-number selfRef">12.8. </a><a href="#name-status-types-2" class="section-name selfRef">Status Types</a>
         </h3>
 <p id="section-12.8-1">As previously explained, there is the danger of observability of Relying Parties and Outsiders. That means that any Status Type that transports special information about a Token can leak information to other parties. This documents defines one additional Status Type with "SUSPENDED" that conveys such additional information. Depending on the use-case, suspended could for example provide information that an authorization in the Token is suspended, but the token itself is still valid.<a href="#section-12.8-1" class="pilcrow">¶</a></p>
 <p id="section-12.8-2">A concrete example would be a driver's license, where the digital driver's license might still be useful to prove other information about its holder, but suspended could signal that it should not be considered valid in the scope of being allowed to drive a car. This case could be solved by either introducing a special status type, or by revoking the Token and re-issuing with changed attributes. For such a case, the status type suspended might be dangerous as it would leak the information of a suspended driver's license even if the driver's license is used as a mean of identification and not in the context of driving a car. This could also allow for the unwanted collection of statistical data on the status of driver's licenses.<a href="#section-12.8-2" class="pilcrow">¶</a></p>
-<p id="section-12.8-3">Ecosystems that want to use other Status Types than "VALID" and "INVALID" should consider the possible leakage of data and profiling possibilities before doing so.<a href="#section-12.8-3" class="pilcrow">¶</a></p>
+<p id="section-12.8-3">Ecosystems that want to use other Status Types than "VALID" and "INVALID" should consider the possible leakage of data and profiling possibilities before doing so and evaluate if revocation and re-issuance might a better fit for their use-case.<a href="#section-12.8-3" class="pilcrow">¶</a></p>
 </section>
 </div>
 </section>

222-suspended-privacy-considerations/draft-ietf-oauth-status-list.txt

@@ -119,7 +119,7 @@ Table of Contents
        12.5.2.  Colluding Status Issuer and Relying Party
      12.6.  Third-Party Hosting
      12.7.  Historical Resolution
-     12.8.  Other Status Types
+     12.8.  Status Types
    13. Implementation Considerations
      13.1.  Referenced Token Lifecycle
      13.2.  Default Values and Double Allocation
@@ -615,9 +615,9 @@ Table of Contents
    d28453a20126106e7374617475736c6973742b637774a1044231325850a502782168
    747470733a2f2f6578616d706c652e636f6d2f7374617475736c697374732f31061a
    648c5bea041a8898dfea19fffe19a8c019fffda2646269747301636c73744a78dadb
-   b918000217015d58400926354c49b182a2e203034c50e296030e1177e8d8380be014
-   bfa1c696469b2fa456e2f191ab6ed44fccf050f074e52013e2d2877fd970d8ad4b73
-   8db01f942e
+   b918000217015d58402135486b1e9dead0fe641f61474c950d9a727b9cb86b09ec7a
+   f48cd0b1a882b3d70ae8c2a195e42ef0e26bec58f23c0b711ea6aaed8fa7c8b61c9d
+   27fad1e8b0
 
    The following is the CBOR Annotated Hex output of the example above:
 
@@ -639,12 +639,12 @@ d2                              # tag(18)
       6269747301636c73744a78da  #       "bits\x01clstJxÚ"
       dbb918000217015d          #       "Û¹\x18\x00\x02\x17\x01]"
     58 40                       #     bytes(64)
-      0926354c49b182a2e203034c  #       "\x09&5LI±\x82¢â\x03\x03L"
-      50e296030e1177e8d8380be0  #       "Pâ\x96\x03\x0e\x11wèØ8\x0bà"
-      14bfa1c696469b2fa456e2f1  #       "\x14¿¡Æ\x96F\x9b/¤Vâñ"
-      91ab6ed44fccf050f074e520  #       "\x91«nÔOÌðPðtå "
-      13e2d2877fd970d8ad4b738d  #       "\x13âÒ\x87\x7fÙpØ\xadKs\x8d"
-      b01f942e                  #       "°\x1f\x94."
+      2135486b1e9dead0fe641f61  #       "!5Hk\x1e\x9dêÐþd\x1fa"
+      474c950d9a727b9cb86b09ec  #       "GL\x95\x0d\x9ar{\x9c¸k\x09ì"
+      7af48cd0b1a882b3d70ae8c2  #       "zô\x8cб¨\x82³×\x0aèÂ"
+      a195e42ef0e26bec58f23c0b  #       "¡\x95ä.ðâkìXò<\x0b"
+      711ea6aaed8fa7c8b61c9d27  #       "q\x1e¦ªí\x8f§È¶\x1c\x9d'"
+      fad1e8b0                  #       "úÑè°"
 
 6.  Referenced Token
 
@@ -789,9 +789,9 @@ d2                              # tag(18)
    d28443a10126a1044231325866a502653132333435017368747470733a2f2f657861
    6d706c652e636f6d061a648c5bea041a8898dfea19ffffa16b7374617475735f6c69
    7374a2636964780063757269782168747470733a2f2f6578616d706c652e636f6d2f
-   7374617475736c697374732f31584080dd28f6190db96a769b6a258a6273e7e1b68d
-   5cac03b144bef26e2e8cbc69a692ee32a74123b71d4f016be20a02a145a7144ca4c6
-   3b9c2b33c56117f1cd32c4
+   7374617475736c697374732f315840caf2aa36cc1f2e2bda113cadb8e3f001c034b2
+   21146b4146553dd838517f82152ad36cba9b82b22411e05f682af0ce5738fc47955c
+   0e4ca2696837273bc0f91c
 
    The following is the CBOR Annotated Hex output of the example above:
 
@@ -814,12 +814,12 @@ d2                              # tag(18)
          2e636f6d2f7374617475736c  #       ".com/statusl"
          697374732f31              #       "ists/1"
        58 40                       #     bytes(64)
-         80dd28f6190db96a769b6a25  #       "\x80Ý(ö\x19\x0d¹jv\x9bj%"
-         8a6273e7e1b68d5cac03b144  #       "\x8absçá¶\x8d\¬\x03±D"
-         bef26e2e8cbc69a692ee32a7  #       "¾òn.\x8c¼i¦\x92î2§"
-         4123b71d4f016be20a02a145  #       "A#·\x1dO\x01kâ\x0a\x02¡E"
-         a7144ca4c63b9c2b33c56117  #       "§\x14L¤Æ;\x9c+3Åa\x17"
-         f1cd32c4                  #       "ñÍ2Ä"
+         caf2aa36cc1f2e2bda113cad  #       "Êòª6Ì\x1f.+Ú\x11<\xad"
+         b8e3f001c034b221146b4146  #       "¸ãð\x01À4²!\x14kAF"
+         553dd838517f82152ad36cba  #       "U=Ø8Q\x7f\x82\x15*Ólº"
+         9b82b22411e05f682af0ce57  #       "\x9b\x82²$\x11à_h*ðÎW"
+         38fc47955c0e4ca269683727  #       "8üG\x95\\x0eL¢ih7'"
+         3bc0f91c                  #       ";Àù\x1c"
 
    ISO mdoc [ISO.mdoc] may utilize the Status List mechanism by
    introducing the status parameter in the Mobile Security Object (MSO)
@@ -1004,6 +1004,8 @@ d2                              # tag(18)
    (Expiration Time) but also has a status of 0x00 ("VALID"), the token
    is considered expired.
 
+   See Section 12.8 for privacy considerations on status types.
+
 8.  Verification and Processing
 
 8.1.  Status List Request
@@ -1047,8 +1049,8 @@ d2                              # tag(18)
    yJleHAiOjIyOTE3MjAxNzAsImlhdCI6MTY4NjkyMDE3MCwiaXNzIjoiaHR0cHM6Ly9le
    GFtcGxlLmNvbSIsInN0YXR1c19saXN0Ijp7ImJpdHMiOjEsImxzdCI6ImVOcmJ1UmdBQ
    WhjQlhRIn0sInN1YiI6Imh0dHBzOi8vZXhhbXBsZS5jb20vc3RhdHVzbGlzdHMvMSIsI
-   nR0bCI6NDMyMDB9.eBXUtWOBswXG3P5Ou9vDAUU2CSRQEmTE3xSFHWnDYLfqCTDHCf4s
-   0hPZ8_LxZHZWnti5TKBE5aphkf4sA99WLQ
+   nR0bCI6NDMyMDB9.hY5OVb-F79wU62js971HSDBQ7PMqKi6G7vtmEOyOEDqaZTKFkQ5F
+   _HwPyN3hpMWd4ocn_MXQksNAD0x5fbOPFQ
 
 8.2.  Status List Response
 
@@ -1186,8 +1188,8 @@ d2                              # tag(18)
    yJleHAiOjIyOTE3MjAxNzAsImlhdCI6MTY4NjkyMDE3MCwiaXNzIjoiaHR0cHM6Ly9le
    GFtcGxlLmNvbSIsInN0YXR1c19saXN0Ijp7ImJpdHMiOjEsImxzdCI6ImVOcmJ1UmdBQ
    WhjQlhRIn0sInN1YiI6Imh0dHBzOi8vZXhhbXBsZS5jb20vc3RhdHVzbGlzdHMvMSIsI
-   nR0bCI6NDMyMDB9.eBXUtWOBswXG3P5Ou9vDAUU2CSRQEmTE3xSFHWnDYLfqCTDHCf4s
-   0hPZ8_LxZHZWnti5TKBE5aphkf4sA99WLQ
+   nR0bCI6NDMyMDB9.hY5OVb-F79wU62js971HSDBQ7PMqKi6G7vtmEOyOEDqaZTKFkQ5F
+   _HwPyN3hpMWd4ocn_MXQksNAD0x5fbOPFQ
 
 9.  Status List Aggregation
 
@@ -1540,7 +1542,7 @@ d2                              # tag(18)
    reasons to do so and after carefully considering the privacy
    implications.
 
-12.8.  Other Status Types
+12.8.  Status Types
 
    As previously explained, there is the danger of observability of
    Relying Parties and Outsiders.  That means that any Status Type that
@@ -1565,7 +1567,8 @@ d2                              # tag(18)
 
    Ecosystems that want to use other Status Types than "VALID" and
    "INVALID" should consider the possible leakage of data and profiling
-   possibilities before doing so.
+   possibilities before doing so and evaluate if revocation and re-
+   issuance might a better fit for their use-case.
 
 13.  Implementation Considerations