Using Quantum-Resistant Key Encapsulation Mechanisms (KEMs) in the Pairwise Mode of Group Object Security for Constrained RESTful Environments (Group OSCORE)

Internet-Draft	Quantum-Resistant KEMs in Group OSCORE	November 2026
Tiloca	Expires 6 May 2027	[Page]

Abstract

Group communication for the Constrained Application Protocol (CoAP) can be protected end-to-end by using the security protocol Group Object Security for Constrained RESTful Environments (Group OSCORE). The pairwise mode of Group OSCORE provides authenticated encryption of CoAP messages, by means of symmetric keys that two group members establish only among themselves to achieve pairwise secure communication. This document defines the use of quantum-resistant Key Encapsulation Mechanisms (KEMs) as Pairwise Key Agreement Algorithm of Group OSCORE, enabling post-quantum secure derivation of the symmetric keys used in the pairwise mode. The Group Manager facilitates the exchange of KEM public keys and encapsulated KEM shared secrets among group members.¶

1. Introduction

The Constrained Application Protocol (CoAP) [RFC7252] also supports group communication [I-D.ietf-core-groupcomm-bis], e.g., over IP multicast. Building on Object Security for Constrained RESTful Environments (OSCORE) [RFC8613], the security protocol Group Object Security for Constrained RESTful Environments (Group OSCORE) [I-D.ietf-core-oscore-groupcomm] provides end-to-end security of CoAP messages when using group communication for CoAP.¶

An OSCORE group is associated with a Group Manager, i.e., an entity responsible for managing identifiers and keying material in the group and for handling the join process to add group members, among other tasks (see Section 12 of [I-D.ietf-core-oscore-groupcomm]).¶

Group OSCORE provides two ways to protect a CoAP message:¶

The group mode, which achieves group-level data confidentiality and provides source authentication by means of a digital signature. The message sender computes the signature with its own private key and embeds it in the protected CoAP message.¶
The pairwise mode, which achieves pairwise data confidentiality and provides source authentication by means of integrity tags. The message sender performs authenticated encryption of the CoAP message by using a symmetric pairwise key that is exclusively shared with another group member as the intended message recipient.¶

Symmetric pairwise keys are derived from a pairwise shared secret, which in turn is computed from asymmetric keys of the message sender and recipient, ensuring authenticated key agreement.¶

In the event that a Cryptographically Relevant Quantum Computer (CRQC) is constructed, it is relatively simple to adapt the group mode of Group OSCORE to be quantum-resistant. That is, it is sufficient to rely on a quantum-resistant signature algorithm (e.g., ML-DSA [FIPS204][RFC9964]) as the Signature Algorithm used in the group (see Section 2.1.8 of [I-D.ietf-core-oscore-groupcomm]).¶

However, equivalent drop-in replacements are not available for the Pairwise Key Agreement Algorithm (see Section 2.1.10 of [I-D.ietf-core-oscore-groupcomm]), which is used to compute the shared secret from which pairwise keys are derived (see Section 2.5.1 of [I-D.ietf-core-oscore-groupcomm]). In particular, the currently available Pairwise Key Agreement Algorithms are based on a direct Elliptic Curve Diffie-Hellman Static-Static key agreement [NIST-800-56A].¶

At the time of writing, there is no standardized Diffie-Hellman/Non-Interactive Key Exchange (DH/NIKE) that can be used for post-quantum secure establishment of the shared secret, which makes the pairwise mode of Group OSCORE vulnerable to quantum attacks. Moreover, a future quantum-resistant DH/NIKE might not be (immediately) usable as a drop-in replacement for Group OSCORE (see Appendix A).¶

This document defines the use of quantum-resistant Key Encapsulation Mechanisms (KEMs), such as ML-KEM [FIPS203], as Pairwise Key Agreement Algorithm of Group OSCORE. Consequently, it enables the post-quantum secure establishment of the shared secret and thus the post-quantum secure derivation of the symmetric keys used in the pairwise mode of Group OSCORE.¶

The Group Manager facilitates the exchange of KEM public keys and encapsulated KEM shared secrets among group members that perform the KEM-based Pairwise Key Agreement Algorithm.¶

1.1. Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

Readers are expected to be familiar with the terms and concepts related to CoAP [RFC7252], OSCORE [RFC8613], Group OSCORE [I-D.ietf-core-oscore-groupcomm], and CBOR Object Signing and Encryption (COSE) [RFC9052].¶

3. Derivation of Pairwise Keys

This section defines how pairwise keys are derived when the Pairwise Key Agreement Algorithm used is a quantum-resistant KEM.¶

Analogous to the construction used by OSCORE in Section 3.2.1 of [RFC8613], the derivation of pairwise keys is aligned with the one defined in Section 2.5.1 of [I-D.ietf-core-oscore-groupcomm], with the difference that two shared secrets are established through the Pairwise Key Agreement Algorithm, and they are separately used to derive a Pairwise Sender Key and the corresponding Pairwise Recipient Key.¶

For a given endpoint, the derivation of the pairwise keys to use between itself and each other endpoint X in the group is as below:¶

Pairwise Sender Key    = HKDF(Sender Key, IKM-Sender, info, L)
Pairwise Recipient Key = HKDF(Recipient Key, IKM-Recipient, info, L)

with

IKM-Sender    = Sender Auth Cred | Recipient Auth Cred |
                Sender Shared Secret
IKM-Recipient = Recipient Auth Cred | Sender Auth Cred |
                Recipient Shared Secret

where:¶

The same as defined in Section 2.5.1 of [I-D.ietf-core-oscore-groupcomm] applies for:¶
- The HMAC-based key derivation function (HKDF) [RFC5869].¶
- The Sender Key, the Recipient Key, info, and L.¶
- Sender Auth Cred and Recipient Auth Cred.¶
- The Pairwise Sender Key, i.e., the AEAD key for processing outgoing messages addressed to endpoint X.¶
- The Pairwise Recipient Key, i.e., the AEAD key for processing incoming messages from endpoint X.¶
IKM-Sender is the Input Keying Material (IKM) used in the HKDF for the derivation of the Pairwise Sender Key. IKM-Sender is the byte string concatenation of Sender Auth Cred, Recipient Auth Cred, and the Sender Shared Secret. The authentication credentials Sender Auth Cred and Recipient Auth Cred are binary encoded as defined in Section 2.4 of [I-D.ietf-core-oscore-groupcomm].¶
IKM-Recipient is the IKM used in the HKDF for the derivation of the Pairwise Recipient Key. IKM-Recipient is the byte string concatenation of Recipient Auth Cred, Sender Auth Cred, and the Recipient Shared Secret. The authentication credentials Recipient Auth Cred and Sender Auth Cred are binary encoded as defined in Section 2.4 of [I-D.ietf-core-oscore-groupcomm].¶
The Sender Shared Secret is computed by the endpoint using the endpoint X's KEM public key, and it is associated with the encapsulated KEM shared secret computed by the endpoint and intended to endpoint X. The Sender Shared Secret of the endpoint is equal to the Recipient Shared Secret of endpoint X.¶
The Recipient Shared Secret is computed by the endpoint using the endpoint's own KEM private key and the encapsulated KEM shared secret from endpoint X. The Recipient Shared Secret of the endpoint is equal to the Sender Shared Secret of endpoint X.¶

For what concerns the derivation of Pairwise Keys, a KEM public key associated with the endpoint is used by any and exactly one other endpoint X in the group to compute exactly one Sender Shared Secret. The endpoint computes the same value as its Recipient Shared Secret using its own KEM private key and the encapsulated KEM shared secret from endpoint X.¶

That is, in order to compute its Sender Shared Secret and derive its Pairwise Sender Key, the endpoint has to obtain the endpoint X's KEM public key. Conversely, in order to compute its Recipient Shared Secret and derive its Pairwise Recipient Key, the endpoint has to obtain the encapsulated KEM shared secret from endpoint X.¶

However, KEM public keys and encapsulated KEM shared secrets are not provided within messages that group members directly send to each other. Instead, group members exchange KEM public keys and encapsulated KEM shared secrets via the Group Manager responsible for the group, as defined in Section 5.¶

5. Assistance from the Group Manager

This section defines the operations that the Group Manager performs to facilitate the exchange of KEM public keys and encapsulated KEM shared secrets among group members, when the Pairwise Key Agreement Algorithm used in the group is a quantum-resistant KEM.¶

The following is not relevant for a node that joins the group exclusively as a silent server (see Section 1.1 of [I-D.ietf-core-oscore-groupcomm]), or that does not support or does not intend to use the pairwise mode in the group.¶

There are different ways to perform such supportive operations, depending on the specific realization of Group Manager. For example, when considering the realization of Group Manager specified in [I-D.ietf-ace-key-groupcomm-oscore] and based on the Authentication and Authorization for Constrained Environments (ACE) framework [RFC9200], it is possible to accordingly extend its interface as defined in [I-D.tiloca-ace-oscore-gm-kem].¶

Given an OSCORE group, the following applies.¶

5.1. Uploading a KEM Public Key

A group member P has to be able to upload its own KEM public keys at the Group Manager. In particular, P can upload a KEM public key at the Group Manager already when joining the group, and then upload other KEM public keys later on as a group member.¶

After generating a KEM public/private key pair, P uploads the KEM public key at the Group Manager. Then, P stores the KEM public key, the corresponding KEM private key, and a SHA-256 hash [SHA-256] of the KEM public key as corresponding identifier.¶

When the Group Manager receives a KEM public key from P, the Group Manager stores the KEM public key as associated with the Sender ID of P in the group. The Group Manager is able to identify P and thereby determine its Sender ID in the group, e.g., by means of the secure communication association shared with P.¶

The Group Manager MUST keep the association between the KEM Public Key and Sender ID of P up-to-date over time, in the event that P changes its Sender ID in the group.¶

The Group Manager is expected to be able to store multiple KEM public keys from the same group member P at any given time, up to a local upper bound. When the group member P is removed from the group, the Group Manager deletes from its local storage any KEM public key of P.¶

A KEM public key of P is intended to be retrieved from the Group Manager and used by any and exactly one other group member.¶

5.2. Retrieving a KEM Public Key

Another group member Q has to be able to retrieve a KEM public key of P from the Group Manager.¶

Q retrieves a KEM public key of P when it wants to send to P a message protected with the pairwise mode and does not have the Pairwise Sender Key required to process the message.¶

In order to retrieve a KEM public key of P from the Group Manager, Q specifies the Sender ID of P to the Group Manager.¶

After the Group Manager provides Q with the KEM public key of P, the Group Manager deletes the KEM public key of P from its local storage.¶

P has to be able to gain knowledge about the number of own KEM public keys that are currently stored at the Group Manager. For example, this can rely on P accessing a dedicated resource hosted by the Group Manager. If such resource is observable [RFC7641], P can use CoAP Observe to subscribe for updates about the resource representation, thereby receiving notifications from the Group Manager.¶

5.3. Uploading an Encapsulated KEM Shared Secret

After Q retrieves a KEM public key of P from the Group Manager (see Section 5.2), Q uses the KEM public key of P to compute the shared secret and produces the encapsulated KEM shared secret intended to P.¶

Q uses the shared secret as the Sender Shared Secret for deriving its own Pairwise Sender Key to use with P (see Section 3). After that, Q stores the Pairwise Sender Key to use with P in its Sender Context, within the Group OSCORE Security Context used in the group (see Section 2 of [I-D.ietf-core-oscore-groupcomm]).¶

Q has to be able to upload the following information at the Group Manager:¶

The encapsulated KEM shared secret.¶
The Sender ID of P, identifying the intended consumer of the encapsulated KEM shared secret.¶
The SHA-256 hash of the KEM public key of P that Q used to compute the shared secret.¶

When the Group Manager receives from Q an encapsulated KEM shared secret intended to P, the Group Manager stores the encapsulated KEM shared secret as associated with the following information:¶

The Sender ID of Q, identifying the producer of the encapsulated KEM shared secret. The Group Manager is able to identify Q and thereby determine its Sender ID in the group, e.g., by means of the secure communication association shared with Q.¶
The Sender ID of P received from Q, identifying the intended consumer of the encapsulated KEM shared secret.¶
The SHA-256 hash received from Q, as the identifier of the KEM public key of P that Q used to compute the shared secret.¶

When doing so, the Group Manager overwrites any already stored encapsulated KEM shared secret and SHA-256 hash identifier that are associated with the same consumer Sender ID and producer Sender ID.¶

The Group Manager MUST keep up-to-date the association between the encapsulated KEM shared secret and the three pieces of information above, in the event that P or Q change their Sender IDs in the group.¶

When a group member is removed from the group, the Group Manager deletes from its local storage any encapsulated KEM shared secret of which that group member is the producer or the intended consumer. For each of such encapsulated KEM shared secrets, the Group Manager also deletes the associated SHA-256 hash identifying a KEM public key, freeing up their association with the consumer Sender ID and producer Sender ID.¶

5.4. Retrieving an Encapsulated KEM Shared Secret

P has to be able to retrieve the following information from the Group Manager:¶

The encapsulated KEM shared secret computed for P by Q.¶
The SHA-256 hash identifier of its own KEM public key that Q used to compute the shared secret.¶

In order to retrieve that information, P specifies the Sender ID of Q to the Group Manager. Then, the Group Manager provides the requested information, if it stores an encapsulated KEM shared secret associated with both:¶

The specified Sender ID of Q, identifying the producer of the encapsulated KEM shared secret; and¶
The Sender ID of P, identifying the intended consumer of the encapsulated KEM shared secret. The Group Manager is able to identify P and thereby determine its Sender ID in the group, e.g., by means of the secure communication association shared with P.¶

After providing P with the encapsulated KEM shared secret and SHA-256 hash identifier, the Group Manager deletes those two pieces of information from its local storage, freeing up their association with the consumer Sender ID and producer Sender ID.¶

P retrieves the encapsulated KEM shared secret computed by Q when it receives from Q a message protected with the pairwise mode and does not have the Pairwise Recipient Key required to process the message.¶

P uses the SHA-256 hash identifier to retrieve its own corresponding KEM public key and KEM private key from its local storage.¶

Then, P computes the shared secret by using its own KEM private key and the encapsulated KEM shared secret computed by Q. After that, P deletes the encapsulated KEM shared secret, and it deletes from its local storage the KEM private key just used as well as the corresponding KEM public key and the corresponding SHA-256 hash identifier.¶

P uses the shared secret as the Recipient Shared Secret for deriving its own Pairwise Recipient Key to use with Q (see Section 3). After that, P stores the Pairwise Recipient Key to use with Q in its Recipient Context associated with Q, within the Group OSCORE Security Context used in the group (see Section 2 of [I-D.ietf-core-oscore-groupcomm]).¶

6. Security Considerations

The security considerations from [I-D.ietf-core-oscore-groupcomm] and [I-D.ietf-cose-pqc-kem] hold for this document too. The security considerations for the specific KEM used as Pairwise Key Agreement Algorithm in the Group OSCORE Security Context also apply. Security considerations for ML-KEM are compiled in [I-D.sfluhrer-cfrg-ml-kem-security-considerations].¶

Using a quantum-resistant KEM typically requires a good source of randomness, e.g., in order to generate KEM public/private keys and to compute shared secrets and encapsulated KEM shared secrets. In turn, for endpoints that use the pairwise mode of Group OSCORE with a quantum-resistant KEM as the Pairwise Key Agreement Algorithm, this requires those endpoints to use a cryptographically secure random number generator.¶

In the case that the Pairwise Key Agreement Algorithm used is not quantum-resistant, an adversary equipped with a CRQC is able to derive a shared secret computed by two group members.¶

Consequently, if the adversary leaks the shared secret to a third group member or if the adversary is in control or such third group member, then the same exploitation discussed in Section 14.2 of [I-D.ietf-core-oscore-groupcomm] is possible.¶

That is, the third group member can derive the pairwise keys of the two group members and use those to impersonate either of the two group members to the other, or to decrypt previously stored messages exchanged between those two members and protected with their pairwise keys. Fundamentally, this would break the following security properties that are expected from the pairwise mode (see Section 14.2 of [I-D.ietf-core-oscore-groupcomm]):¶

Symmetric source authentication, as it becomes possible to impersonate either group member when sending a message protected with the pairwise mode.¶
Symmetric pairwise confidentiality, as a message protected with the pairwise mode becomes possible to decrypt also for other group members than the two intended ones.¶

8. References

8.1. Normative References

[COSE.Algorithms]: IANA, "COSE Algorithms", <https://www.iana.org/assignments/cose/cose.xhtml#algorithms>.
[FIPS203]: "Module-Lattice-Based Key-Encapsulation Mechanism Standard", NIST FIPS 203, August 2024, <https://doi.org/10.6028/NIST.FIPS.203>.
[I-D.ietf-core-groupcomm-bis]: Dijk, E. and M. Tiloca, "Group Communication for the Constrained Application Protocol (CoAP)", Work in Progress, Internet-Draft, draft-ietf-core-groupcomm-bis-18, 10 February 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-core-groupcomm-bis-18>.
[I-D.ietf-core-oscore-groupcomm]: Tiloca, M., Selander, G., Palombini, F., Mattsson, J. P., and R. Höglund, "Group Object Security for Constrained RESTful Environments (Group OSCORE)", Work in Progress, Internet-Draft, draft-ietf-core-oscore-groupcomm-28, 23 December 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-core-oscore-groupcomm-28>.
[I-D.ietf-cose-pqc-kem]: Reddy.K, T., Banerjee, A., and H. Tschofenig, "Post-Quantum Key Encapsulation Mechanisms (PQ KEMs) for COSE", Work in Progress, Internet-Draft, draft-ietf-cose-pqc-kem-00, 29 October 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-cose-pqc-kem-00>.
[RFC2119]: Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.
[RFC5869]: Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", RFC 5869, DOI 10.17487/RFC5869, May 2010, <https://www.rfc-editor.org/rfc/rfc5869>.
[RFC7252]: Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, <https://www.rfc-editor.org/rfc/rfc7252>.
[RFC7641]: Hartke, K., "Observing Resources in the Constrained Application Protocol (CoAP)", RFC 7641, DOI 10.17487/RFC7641, September 2015, <https://www.rfc-editor.org/rfc/rfc7641>.
[RFC8174]: Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8613]: Selander, G., Mattsson, J., Palombini, F., and L. Seitz, "Object Security for Constrained RESTful Environments (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, <https://www.rfc-editor.org/rfc/rfc8613>.
[RFC9052]: Schaad, J., "CBOR Object Signing and Encryption (COSE): Structures and Process", STD 96, RFC 9052, DOI 10.17487/RFC9052, August 2022, <https://www.rfc-editor.org/rfc/rfc9052>.
[SHA-256]: NIST, "Secure Hash Standard", NIST FIPS PUB 180-4, DOI 10.6028/NIST.FIPS.180-4 , August 2015, <https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf>.

8.2. Informative References

[FIPS204]: "Module-Lattice-Based Digital Signature Standard", NIST FIPS 204, August 2024, <https://doi.org/10.6028/NIST.FIPS.204>.
[I-D.ietf-ace-key-groupcomm-oscore]: Tiloca, M. and F. Palombini, "Key Management for Group Object Security for Constrained RESTful Environments (Group OSCORE) Using Authentication and Authorization for Constrained Environments (ACE)", Work in Progress, Internet-Draft, draft-ietf-ace-key-groupcomm-oscore-21, 14 March 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-ace-key-groupcomm-oscore-21>.
[I-D.sfluhrer-cfrg-ml-kem-security-considerations]: Fluhrer, S., Dang, Q., Mattsson, J. P., Milner, K., and D. Shiu, "ML-KEM Security Considerations", Work in Progress, Internet-Draft, draft-sfluhrer-cfrg-ml-kem-security-considerations-05, 13 May 2026, <https://datatracker.ietf.org/doc/html/draft-sfluhrer-cfrg-ml-kem-security-considerations-05>.
[I-D.tiloca-ace-oscore-gm-kem]: Tiloca, M., "Quantum-Resistant Key Encapsulation Mechanisms (KEMs) via the OSCORE Group Manager Using Authentication and Authorization for Constrained Environments (ACE)", Work in Progress, Internet-Draft, draft-tiloca-ace-oscore-gm-kem-00, 6 July 2026, <https://datatracker.ietf.org/doc/html/draft-tiloca-ace-oscore-gm-kem-00>.
[NIST-800-56A]: Barker, E., Chen, L., Roginsky, A., Vassilev, A., and R. Davis, "Recommendation for Pair-Wise Key-Establishment Schemes Using Discrete Logarithm Cryptography - NIST Special Publication 800-56A, Revision 3", April 2018, <https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Ar3.pdf>.
[RFC9200]: Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and H. Tschofenig, "Authentication and Authorization for Constrained Environments Using the OAuth 2.0 Framework (ACE-OAuth)", RFC 9200, DOI 10.17487/RFC9200, August 2022, <https://www.rfc-editor.org/rfc/rfc9200>.
[RFC9964]: Prorock, M. and O. Steele, "ML-DSA for JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE)", RFC 9964, DOI 10.17487/RFC9964, May 2026, <https://www.rfc-editor.org/rfc/rfc9964>.

Appendix A. Prospective KEMs Based on a DH/NIKE

The construct defined in this document makes it seamlessly possible to use as Pairwise Key Agreement Algorithm of Group OSCORE also a KEM that builds on a quantum-resistant DH/NIKE, when one is available.¶

For example, assuming that a quantum-resistant equivalent of Elliptic Curve Diffie-Hellman exists, the following would apply:¶

The encapsulated KEM shared secret is the ephemeral Diffie-Hellman public key of the endpoint that computes the shared secret first.¶
The KEM public/private key is the ephemeral Diffie-Hellman public/private key of the endpoint that computes the shared secret last.¶

The ability to build such a KEM to use as Pairwise Key Agreement Algorithm is expected to be useful in the future: Even when a standardized, quantum-resistant DH/NIKE exists and is defined for COSE as registered at [COSE.Algorithms], it might not be (immediately) possible to directly use such DH/NIKE in Group OSCORE.¶

In the particular case where an OSCORE group uses only the pairwise mode, such a DH/NIKE can be directly used as Pairwise Key Agreement Algorithm. Consequently, pairwise keys are derived like originally defined in Section 2.5.1 of [I-D.ietf-core-oscore-groupcomm].¶

Instead, in the case where an OSCORE group uses both the group mode and the pairwise mode, authentication credentials of group members correspond to public/private key pairs to use for signature operations, as per the Signature Algorithm used in the group. Therefore, consistent with the security properties of Group OSCORE, the direct use of such a DH/NIKE requires that all the following conditions are fulfilled:¶

The public/private key pairs associated with group members' authentication credentials can be used for both signature operations and static-static key agreement operations, as per the Signature Algorithm and Pairwise Key Agreement Algorithm used in the group.¶
The use of the same public/private key pair for both signature operations and key agreement operations is proven to be secure for Group OSCORE.¶

Until such conditions are fulfilled, the Pairwise Key Agreement Algorithm used can be a KEM that builds on the quantum-resistant DH/NIKE, with pairwise keys derived as defined in this document.¶

Using Quantum-Resistant Key Encapsulation Mechanisms (KEMs) in the Pairwise Mode of Group Object Security for Constrained RESTful Environments (Group OSCORE)

Abstract

Discussion Venues

Status of This Memo

Copyright Notice

Table of Contents