diff --git a/draft-ietf-ace-oscore-profile.xml b/draft-ietf-ace-oscore-profile.xml index d4b05e2..7584f50 100644 --- a/draft-ietf-ace-oscore-profile.xml +++ b/draft-ietf-ace-oscore-profile.xml @@ -5,13 +5,15 @@ + + + - @@ -98,11 +100,11 @@
- This document specifies a profile of the ACE framework . In this profile, a client and a resource server use the Constrained Application Protocol (CoAP) to communicate. The client uses an access token, bound to a symmetric key (the proof-of-possession key) to authorize its access to the resource server. Note that this profile uses a symmetric-crypto-based scheme, where the symmetric secret is used as input material for keying material derivation. In order to provide communication security and proof of possession, the client and resource server use Object Security for Constrained RESTful Environments (OSCORE) . Note that the proof of possession is not achieved through a dedicated protocol element, but rather occurs after the first message exchange using OSCORE. + This document specifies the "coap_oscore" profile of the ACE framework . In this profile, a client and a resource server use the Constrained Application Protocol (CoAP) to communicate. The client uses an access token, bound to a symmetric key (the proof-of-possession key) to authorize its access to the resource server. Note that this profile uses a symmetric-crypto-based scheme, where the symmetric secret is used as input material for keying material derivation. In order to provide communication security and proof of possession, the client and resource server use Object Security for Constrained RESTful Environments (OSCORE) . Note that the proof of possession is not achieved through a dedicated protocol element, but rather occurs after the first message exchange using OSCORE. - OSCORE specifies how to use CBOR Object Signing and Encryption (COSE) to secure CoAP messages. + OSCORE specifies how to use CBOR Object Signing and Encryption (COSE) to secure CoAP messages. Note that OSCORE can be used to secure CoAP messages, as well as HTTP and combinations of HTTP and CoAP; a profile of ACE similar to the one described in this document, with the difference of using HTTP instead of CoAP as communication protocol, could be specified analogously to this one. @@ -117,7 +119,7 @@ - Certain security-related terms such as "authentication", "authorization", "confidentiality", "(data) integrity", "message authentication code", and "verify" are taken from . + Certain security-related terms such as "authentication", "authorization", "confidentiality", "(data) integrity", "Message Authentication Code (MAC)", “Hash-based Message Authentication Code (HMAC)”, and "verify" are taken from . @@ -139,7 +141,10 @@ Note that the term "endpoint" is used here, as in , following its OAuth definition, which is to denote resources such as token and introspect at the AS and authz-info at the RS. The CoAP definition, which is "An entity participating in the CoAP protocol" is not used in this document. - + + + Examples throughout this document are expressed in CBOR diagnostic notation without the tag and value abbreviations. +
@@ -156,7 +161,7 @@ - This profile requires a client to retrieve an access token from the AS for the resource it wants to access on an RS, by sending an access token request to the token endpoint, as specified in section 5.8 of . The access token request and response MUST be confidentiality-protected and ensure authenticity. This profile RECOMMENDS the use of OSCORE between client and AS, to reduce the number of libraries the client has to support, but other protocols fulfilling the security requirements defined in section 5 of (such as TLS or DTLS ) MAY be used as well. + This profile requires a client to retrieve an access token from the AS for the resource it wants to access on an RS, by sending an access token request to the token endpoint, as specified in section 5.8 of . The access token request and response MUST be confidentiality-protected and ensure authenticity. This profile RECOMMENDS the use of OSCORE between client and AS, to reduce the number of libraries the client has to support, but other protocols fulfilling the security requirements defined in section 5 of MAY alternatively be used, such as TLS or DTLS . @@ -173,7 +178,7 @@ - Finally, the client starts the communication with the RS by sending a request protected with OSCORE to the RS. If the request is successfully verified, the server stores the complete Security Context state that is ready for use in protecting messages, and uses it in the response, and in further communications with the client, until token deletion, due to e.g. expiration. This Security Context is discarded when a token (whether the same or a different one) is used to successfully derive a new Security Context for that client. + Finally, the client starts the communication with the RS by sending a request protected with OSCORE to the RS. If the request is successfully verified, the server stores the complete Security Context state that is ready for use in protecting messages, and uses it in the response, and in further communications with the client, until token deletion due to, for example, expiration. This Security Context is discarded when a token (whether the same or a different one) is used to successfully derive a new Security Context for that client. @@ -249,7 +254,7 @@ Sec Context storage/ | | - An example of such a request, with payload in CBOR diagnostic notation without the tag and value abbreviations is reported in + An example of such a request is shown in
@@ -260,7 +265,7 @@ Sec Context storage/ | | Content-Format: "application/ace+cbor" Payload: { - "req_aud" : "tempSensor4711", + "audience" : "tempSensor4711", "scope" : "read" } ]]> @@ -268,11 +273,11 @@ Sec Context storage/ | |
- If the client wants to update its access rights without changing an existing OSCORE Security Context, it MUST include in its POST request to the token endpoint a req_cnf object, with the kid field carrying a CBOR byte string containing the OSCORE Input Material Identifier (assigned as discussed in ). This identifier, together with other information such as audience (see Section 5.8.1 of ), can be used by the AS to determine the shared secret bound to the proof-of-possession token and therefore MUST identify a symmetric key that was previously generated by the AS as a shared secret for the communication between the client and the RS. The AS MUST verify that the received value identifies a proof-of-possession key that has previously been issued to the requesting client. If that is not the case, the Client-to-AS request MUST be declined with the error code 'invalid_request' as defined in Section 5.8.3 of . + If the client wants to update its access rights without changing an existing OSCORE Security Context, it MUST include in its POST request to the token endpoint a req_cnf object, with the kid field carrying a CBOR byte string containing the OSCORE Input Material Identifier (assigned as discussed in ). This identifier, together with other information such as audience (see Section 5.8.1 of ), can be used by the AS to determine the shared secret bound to the proof-of-possession token and therefore MUST identify a symmetric key that was previously generated by the AS as a shared secret for the communication between the client and the RS. The AS MUST verify that the received value identifies a proof-of-possession key that has previously been issued to the requesting client. If that is not the case, the Client-to-AS request MUST be declined with the error code invalid_request as defined in Section 5.8.3 of . - An example of such a request, with payload in CBOR diagnostic notation without the tag and value abbreviations is reported in + An example of such a request is shown in
@@ -283,7 +288,7 @@ Sec Context storage/ | | Content-Format: "application/ace+cbor" Payload: { - "req_aud" : "tempSensor4711", + "audience" : "tempSensor4711", "scope" : "write", "req_cnf" : { "kid" : h'01' @@ -325,28 +330,28 @@ Usually it is assumed that constrained devices will be pre-configured with the n a context identifier an AEAD algorithm - an HMAC-based key derivation function (HKDF) algorithm + an HMAC-based key derivation function (HKDF, ) algorithm, see section 3.1 of a salt the OSCORE version number - This data is transported in the OSCORE_Input_Material. The OSCORE_Input_Material is a CBOR map object, defined in . This object is transported in the 'cnf' parameter of the access token response as defined in Section 3.2 of , as the value of a field named 'osc', registered in and . + This data is transported in the OSCORE_Input_Material. The OSCORE_Input_Material is a CBOR map object, defined in . This object is transported in the cnf parameter of the access token response as defined in Section 3.2 of , as the value of a field named osc, registered in and . - The AS MAY assign an identifier to the context (context identifier). This identifier is used as ID Context in the OSCORE context as described in section 3.1 of . If assigned, this parameters MUST be communicated as the 'contextId' field in the OSCORE_Input_Material. The application needs to consider that this identifier is sent in the clear and may reveal information about the endpoints, as mentioned in section 12.8 of . + The AS MAY assign an identifier to the context (context identifier). This identifier is used as ID Context in the OSCORE context as described in section 3.1 of . If assigned, this parameters MUST be communicated as the contextId field in the OSCORE_Input_Material. The application needs to consider that this identifier is sent in the clear and may reveal information about the endpoints, as mentioned in section 12.8 of . - The master secret and the identifier of the OSCORE_Input_Material MUST be communicated as the 'ms' and 'id' field in the 'osc' field in the 'cnf' parameter of the access token response. - If included, the AEAD algorithm is sent in the 'alg' parameter in the OSCORE_Input_Material; the HKDF algorithm in the 'hkdf' parameter of the OSCORE_Input_Material; a salt in the 'salt' parameter of the OSCORE_Input_Material; and the OSCORE version in the 'version' parameter of the OSCORE_Input_Material. + The master secret and the identifier of the OSCORE_Input_Material MUST be communicated as the ms and id field in the osc field in the cnf parameter of the access token response. + If included, the AEAD algorithm is sent in the alg parameter in the OSCORE_Input_Material; the HKDF algorithm in the hkdf parameter of the OSCORE_Input_Material; a salt in the salt parameter of the OSCORE_Input_Material; and the OSCORE version in the version parameter of the OSCORE_Input_Material. The same parameters MUST be included in the claims associated with the access token. - The OSCORE master secret MUST be encrypted by the authorization server so that only the resource server can decrypt it (see Section 6.1. of ). This profile RECOMMENDS the use of CBOR web token (CWT) protected with COSE_Encrypt/COSE_Encrypt0 as specified in . If the token is a CWT, the same OSCORE_Input_Material structure defined above MUST be placed in the 'osc' field of the 'cnf' claim of this token. + The OSCORE master secret MUST be encrypted by the authorization server so that only the resource server can decrypt it (see Section 6.1. of ). This profile RECOMMENDS the use of a CBOR web token (CWT) protected with COSE_Encrypt/COSE_Encrypt0 as specified in . If the token is a CWT, the same OSCORE_Input_Material structure defined above MUST be placed in the osc field of the cnf claim of this token. @@ -354,7 +359,7 @@ Usually it is assumed that constrained devices will be pre-configured with the n - shows an example of an AS response, with payload in CBOR diagnostic notation without the tag and value abbreviations. The access token has been truncated for readability. + shows an example of an AS response. The access token has been truncated for readability.
@@ -370,7 +375,7 @@ Usually it is assumed that constrained devices will be pre-configured with the n "cnf" : { "osc" : { "id" : h'01', - "ms" : h'f9af838368e353e78888e1426bd94e6f' + "ms" : h'f9af838368e353e78888e1426bd94e6f' } } } @@ -379,7 +384,7 @@ Usually it is assumed that constrained devices will be pre-configured with the n
- shows an example CWT Claims Set, including the relevant OSCORE parameters in the 'cnf' claim, in CBOR diagnostic notation without tag and value abbreviations. + shows an example CWT Claims Set, including the relevant OSCORE parameters in the cnf claim.
@@ -402,7 +407,7 @@ Usually it is assumed that constrained devices will be pre-configured with the n - The same CWT Claims Set as in , using the value abbreviations defined in and and encoded in CBOR is shown in . The bytes in hexadecimal are reported in the first column, while their corresponding CBOR meaning is reported after the '#' sign on the second column, for easiness of readability. + The same CWT Claims Set as in , using the value abbreviations defined in and and encoded in CBOR is shown in . The bytes in hexadecimal are reported in the first column, while their corresponding CBOR meaning is reported after the # sign on the second column, for easiness of readability. @@ -452,11 +457,11 @@ A5 # map(5) - If the client has requested an update to its access rights using the same OSCORE Security Context, which is valid and authorized, the AS MUST omit the 'cnf' parameter in the response, and MUST carry the OSCORE Input Material identifier in the 'kid' field in the 'cnf' claim of the token. This identifier needs to be included in the token in order for the RS to identify the correct OSCORE Input Material. + If the client has requested an update to its access rights using the same OSCORE Security Context, which is valid and authorized, the AS MUST omit the cnf parameter in the response, and MUST carry the OSCORE Input Material identifier in the kid field in the cnf claim of the token. This identifier needs to be included in the token in order for the RS to identify the correct OSCORE Input Material. - shows an example of such an AS response, with payload in CBOR diagnostic notation without the tag and value abbreviations. The access token has been truncated for readability. + shows an example of such an AS response The access token has been truncated for readability.
@@ -475,7 +480,7 @@ A5 # map(5)
- shows an example CWT Claims Set, containing the necessary OSCORE parameters in the 'cnf' claim for update of access rights, in CBOR diagnostic notation without tag and value abbreviations. + shows an example CWT Claims Set, containing the necessary OSCORE parameters in the cnf claim for update of access rights.
@@ -502,7 +507,7 @@ A5 # map(5)
- An OSCORE_Input_Material is an object that represents the input material to derive an OSCORE Security Context, i.e., the local set of information elements necessary to carry out the cryptographic operations in OSCORE (Section 3.1 of ). In particular, the OSCORE_Input_Material is defined to be serialized and transported between nodes, as specified by this document, but can also be used by other specifications if needed. The OSCORE_Input_Material can either be encoded as a JSON object or as a CBOR map. The set of common parameters that can appear in an OSCORE_Input_Material can be found in the IANA "OSCORE Security Context Parameters" registry (), defined for extensibility, and is specified below. + An OSCORE_Input_Material is an object that represents the input material to derive an OSCORE Security Context, i.e., the local set of information elements necessary to carry out the cryptographic operations in OSCORE (Section 3.1 of ). In particular, the OSCORE_Input_Material is defined to be serialized and transported between nodes, as specified by this document, but can also be used by other specifications if needed. The OSCORE_Input_Material can either be encoded as a JSON object or as a CBOR map. The set of common parameters that can appear in an OSCORE_Input_Material can be found in the IANA "OSCORE Security Context Parameters" registry (), defined for extensibility, and the initial set of parameters defined in this document is specified below. All parameters are optional. provides a summary of the OSCORE_Input_Material parameters defined in this section. @@ -547,7 +552,7 @@ A5 # map(5) This parameter identifies the OSCORE HKDF Algorithm. For more information about this field, see section 3.1 of . - The values used MUST be registered in the IANA "COSE Algorithms" registry (see ) and MUST be HMAC-based HKDF algorithms. The value can either be the integer or the text string value of the HMAC-based HKDF algorithm in the "COSE Algorithms" registry. + The values used MUST be registered in the IANA "COSE Algorithms" registry (see ) and MUST be HMAC-based HKDF algorithms (see section 3.1 of ). The value can either be the integer or the text string value of the HMAC-based HKDF algorithm in the "COSE Algorithms" registry. In JSON, the "hkdf" value is a case-sensitive ASCII string or an integer. In CBOR, the "hkdf" type is text string or integer, and has label 3. @@ -638,7 +643,7 @@ OSCORE_Input_Material = {
- The client MUST generate a nonce value N1 very unlikely to have been previously used with the same input keying material. This profile RECOMMENDS to use a 64-bit long random number as nonce's value. The client MUST store the nonce N1 as long as the response from the RS is not received and the access token related to it is still valid (to the best of the client's knowledge). + The client MUST generate a nonce value N1 very unlikely to have been previously used with the same input keying material. This profile RECOMMENDS using a 64-bit long random number as the nonce's value. The client MUST store the nonce N1 as long as the response from the RS is not received and the access token related to it is still valid (to the best of the client's knowledge). @@ -650,7 +655,7 @@ OSCORE_Input_Material = { - Note that the use of the payload and the Content-Format is different from what is described in section 5.8.1 of , which only transports the token without any CBOR wrapping. In this profile, the client MUST wrap the token, N1 and ID1 in a CBOR map. The client MUST use the Content-Format "application/ace+cbor" defined in section 8.14 of . The client MUST include the access token using the 'access_token' parameter, N1 using the 'nonce1' parameter defined in , and ID1 using the 'ace_client_recipientid' parameter defined in . + Note that the use of the payload and the Content-Format is different from what is described in section 5.8.1 of , which only transports the token without any CBOR wrapping. In this profile, the client MUST wrap the token, N1 and ID1 in a CBOR map. The client MUST use the Content-Format "application/ace+cbor" defined in section 8.14 of . The client MUST include the access token using the access_token parameter, N1 using the nonce1 parameter defined in , and ID1 using the ace_client_recipientid parameter defined in . @@ -662,11 +667,11 @@ OSCORE_Input_Material = { - The client may also choose to re-POST the access token in order to renew its OSCORE Security Context. In that case, the client and the RS will exchange newly generated nonces, re-negotiate identifiers, and derive new keying material. The client and RS might decide to keep the same identifiers or renew them during the re-negotiation. + The client may also choose to re-POST the access token in order to update its OSCORE Security Context. In that case, the client and the RS will exchange newly generated nonces, re-negotiate identifiers, and derive new keying material. The client and RS might decide to keep the same identifiers or renew them during the re-negotiation. - shows an example of the request sent from the client to the RS, with payload in CBOR diagnostic notation without the tag and value abbreviations. The access token has been truncated for readability. + shows an example of the request sent from the client to the RS. The access token has been truncated for readability.
@@ -687,7 +692,7 @@ OSCORE_Input_Material = {
- If the client has already posted a valid token, has already established a security association with the RS, and wants to update its access rights, the client can do so by posting the new token (retrieved from the AS and containing the update of access rights) to the /authz-info endpoint. The client MUST protect the request using the OSCORE Security Context established during the first token exchange. The client MUST only send the 'access_token' field in the CBOR map in the payload, no nonce or identifier are sent. After proper verification (see ), the RS will replace the old token with the new one, maintaining the same Security Context. + If the client has already posted a valid token, has already established a security association with the RS, and wants to update its access rights, the client can do so by posting the new token (retrieved from the AS and containing the update of access rights) to the /authz-info endpoint. The client MUST protect the request using the OSCORE Security Context established during the first token exchange. The client MUST only send the access_token field in the CBOR map in the payload, no nonce or identifier are sent. After proper verification (see ), the RS will replace the old token with the new one, maintaining the same Security Context.
@@ -711,12 +716,12 @@ OSCORE_Input_Material = {
- The RS MUST follow the procedures defined in section 5.8.1 of : the RS must verify the validity of the token. If the token is valid, the RS must respond to the POST request with 2.01 (Created). If the token is valid but is associated to claims that the RS cannot process (e.g., an unknown scope), or if any of the expected parameters is missing (e.g., any of the mandatory parameters from the AS or the identifier 'id1'), or if any parameters received in the 'osc' field is unrecognized, the RS must respond with an error response code equivalent to the CoAP code 4.00 (Bad Request). In the latter two cases, the RS may provide additional information in the error response, in order to clarify what went wrong. + The RS MUST follow the procedures defined in section 5.8.1 of : the RS must verify the validity of the token. If the token is valid, the RS must respond to the POST request with 2.01 (Created). If the token is valid but is associated to claims that the RS cannot process (e.g., an unknown scope), or if any of the expected parameters is missing (e.g., any of the mandatory parameters from the AS or the identifier id1), or if any parameters received in the osc field is unrecognized, the RS must respond with an error response code equivalent to the CoAP code 4.00 (Bad Request). In the latter two cases, the RS may provide additional information in the error response, in order to clarify what went wrong. The RS may make an introspection request (see Section 5.9.1 of ) to validate the token before responding to the POST request to the authz-info endpoint. - Additionally, the RS MUST generate a nonce N2 very unlikely to have been previously used with the same input keying material, and its own Recipient ID, ID2. The RS makes sure that ID2 does not collide with any of its Recipient IDs. The RS MUST ensure that ID2 is different from the value received in the ace_client_recipientid parameter. The RS sends N2 and ID2 within the 2.01 (Created) response. The payload of the 2.01 (Created) response MUST be a CBOR map containing the 'nonce2' parameter defined in , set to N2, and the 'ace_server_recipientid' parameter defined in , set to ID2. This profile RECOMMENDS to use a 64-bit long random number as nonce's value. The RS MUST use the Content-Format "application/ace+cbor" defined in section 8.14 of . + Additionally, the RS MUST generate a nonce N2 very unlikely to have been previously used with the same input keying material, and its own Recipient ID, ID2. The RS makes sure that ID2 does not collide with any of its Recipient IDs. The RS MUST ensure that ID2 is different from the value received in the ace_client_recipientid parameter. The RS sends N2 and ID2 within the 2.01 (Created) response. The payload of the 2.01 (Created) response MUST be a CBOR map containing the nonce2 parameter defined in , set to N2, and the ace_server_recipientid parameter defined in , set to ID2. This profile RECOMMENDS using a 64-bit long random number as the nonce's value. The RS MUST use the Content-Format "application/ace+cbor" defined in section 8.14 of . - shows an example of the response sent from the RS to the client, with payload in CBOR diagnostic notation without the tag and value abbreviations. + shows an example of the response sent from the RS to the client.
@@ -747,7 +752,7 @@ OSCORE_Input_Material = { - If the RS receives the token in a OSCORE protected message, it means that the client is requesting an update of access rights. The RS MUST ignore any nonce and identifiers in the request, if any was sent. The RS MUST check that the "kid" of the 'cnf' claim of the new access token matches the identifier of the OSCORE Input Material of the context used to protect the message. If that is the case, the RS MUST overwrite the old token and associate the new token to the Security Context identified by the "kid" value in the 'cnf' claim. The RS MUST respond with a 2.01 (Created) response protected with the same Security Context, with no payload. If any verification fails, the RS MUST respond with a 4.01 (Unauthorized) error response. + If the RS receives the token in a OSCORE protected message, it means that the client is requesting an update of access rights. The RS MUST ignore any nonce and identifiers in the request, if any was sent. The RS MUST check that the "kid" of the cnf claim of the new access token matches the identifier of the OSCORE Input Material of the context used to protect the message. If that is the case, the RS MUST overwrite the old token and associate the new token to the Security Context identified by the "kid" value in the cnf claim. The RS MUST respond with a 2.01 (Created) response protected with the same Security Context, with no payload. If any verification fails, the RS MUST respond with a 4.01 (Unauthorized) error response. @@ -774,7 +779,7 @@ OSCORE_Input_Material = {
- Once receiving the 2.01 (Created) response from the RS, following the POST request to authz-info endpoint, the client MUST extract the bstr nonce N2 from the 'nonce2' parameter in the CBOR map in the payload of the response. Then, the client MUST set the Master Salt of the Security Context created to communicate with the RS to the concatenation of salt, N1, and N2, in this order: Master Salt = salt | N1 | N2, where | denotes byte string concatenation, where salt is the CBOR byte string received from the AS in , and where N1 and N2 are the two nonces encoded as CBOR byte strings. An example of Master Salt construction using CBOR encoding is given in . + Once the 2.01 (Created) response is received from the RS, following the POST request to authz-info endpoint, the client MUST extract the bstr nonce N2 from the nonce2 parameter in the CBOR map in the payload of the response. Then, the client MUST set the Master Salt of the Security Context created to communicate with the RS to the concatenation of salt, N1, and N2, in this order: Master Salt = salt | N1 | N2, where | denotes byte string concatenation, where salt is the CBOR byte string received from the AS in , and where N1 and N2 are the two nonces encoded as CBOR byte strings. An example of Master Salt construction using CBOR encoding is given in .
@@ -879,7 +884,7 @@ token. the Sequence Number space ends. - the access token associated with the context becomes invalid, due to e.g. expiration. + the access token associated with the context becomes invalid due to, for example, expiration. the client receives a number of 4.01 Unauthorized responses to OSCORE requests using the same Security Context. The exact number needs to be specified by the application. the client receives a new nonce in the 2.01 (Created) response (see ) to a POST request to the authz-info endpoint, when re-posting a (non-expired) token associated to the existing context. @@ -898,7 +903,7 @@ token. - Whenever one more access token is successfully posted to the RS, and a new Security Context is derived between the client and RS, messages in transit that were protected with the previous Security Context might not pass verification, as the old context is discarded. That means that messages sent shortly before the client posts one more access token to the RS might not successfully reach the destination. Analogously, implementations may want to cancel CoAP observations at the RS registered before the Security Context is replaced, or conversely they will need to implement a mechanism to ensure that those observation are to be protected with the newly derived Security Context. + Whenever one more access token is successfully posted to the RS, and a new Security Context is derived between the client and RS, messages in transit that were protected with the previous Security Context might not pass verification, as the old context is discarded. That means that messages sent shortly before the client posts one more access token to the RS might not successfully reach the destination. Analogously, implementations may want to cancel CoAP observations at the RS registered before the Security Context is replaced, or conversely they will need to implement a mechanism to ensure that those observations are to be protected with the newly derived Security Context.
@@ -919,8 +924,8 @@ token. - As previously stated, the proof-of-possession in this profile is performed by both parties verifying that they have established the same Security Context, as specified in , which means that both the OSCORE request and OSCORE response pass verification. - RS authentication requires both that the client trusts the AS and that the OSCORE response from the RS pass verification. + As previously stated, the proof-of-possession in this profile is performed by both parties verifying that they have established the same Security Context, as specified in , which means that both the OSCORE request and the OSCORE response passes verification. + RS authentication requires both that the client trusts the AS and that the OSCORE response from the RS passes verification. @@ -985,7 +990,7 @@ token.
Note to RFC Editor: Please replace all occurrences of "&SELF;" - with the RFC number of this document and delete this paragraph. + with the RFC number of this document. Please add a reference to the IANA ACE Profile registry in the nextt subsection once it has been created by IANA, and then delete this paragraph.
@@ -1010,7 +1015,7 @@ token.
The following registrations are done for the OAuth Parameters - Registry following the procedure specified in section 11.2 of following the procedure specified in section 11.2 of : @@ -1153,7 +1158,7 @@ token.
- The following registration is done for the CWT Confirmation Methods Registry following the procedure specified in section 7.2.1 of : + The following registration is done for the CWT Confirmation Methods Registry following the procedure specified in section 7.2.1 of : Confirmation Method Name: "osc" @@ -1174,7 +1179,7 @@ token.
- The following registration is done for the JWT Confirmation Methods Registry following the procedure specified in section 6.2.1 of : + The following registration is done for the JWT Confirmation Methods Registry following the procedure specified in section 6.2.1 of : Confirmation Method Value: "osc" @@ -1238,9 +1243,41 @@ token. &RFC8392; &RFC2119; &RFC7252; - &RFC8152; + &I-D.ietf-cose-rfc8152bis-struct; + &I-D.ietf-cose-rfc8152bis-algs; &RFC8174; &RFC8610; + &RFC5869; + + + + OAuth Parameters + + IANA + + + + + + + + CWT Confirmation Methods + + IANA + + + + + + + + JWT Confirmation Methods + + IANA + + + +