Internet-Draft | reclaimid | April 2024 |
Schanzenbach & Grothoff | Expires 10 October 2024 | [Page] |
This document contains the re:claimID technical specification.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any 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 10 October 2024.¶
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
re:claimID is a decentralized, self-sovereign identity management system. It allows users to be in control over their digital identities without having to rely on central identity provider services (IdPs) in order to share personal data.¶
re:claimID is built upon the GNU Name System [GNS] for data sharing and storage. It leverages the zone privacy and key blinding properties of the name system in order to provide a secure sharing and authorization mechanism.¶
The system supports both "self-asserted" as well as third party asserted identity attributes. The assertion mechanisms are out of scope of this document.¶
The re:claimID system can used and integrated into the OpenID Connect protocol.¶
This document defines the normative wire format of resource records, resolution processes, cryptographic routines and security considerations for use by implementors.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].¶
An identity in re:claimID is defined through a zone in GNS. As such, the creation of a zone in GNS implicitly also creates a re:claimID identity.¶
A re:claimID identity attribute is stored in GNS under records of type "RECLAIM_ATTRIBUTE". An attribute consists of an identifier, an optional attestation identifier, a type, a flag, a name and data. The record format of a RECLAIM_ATTRIBUTE is as follows:¶
where:¶
A re:claimID credential is stored in GNS under records of type "RECLAIM_CREDENTIAL". A credential consists of an identifier, a type, a flag, a name and data. The record format of a RECLAIM_CREDENTIAL is as follows:¶
where:¶
In order to share a set of identity attributes with a third party, re:claimID introduces the concept of "Tickets". A Ticket may be issued by a user for an identity to a relying party. The Ticket may then be used by the relying party to retrieve the shared attributes from the name system.¶
A ticket is a GNS name that points to information pertaining to the authorization given to the relying party. The ticket has the format:¶
The TID essentially serves as a shared secret between user and relying party. knowledge of the IDENTITY key and the TID allows the relying party to iteratively query attribute data in GNS. The record set under the TID label contains references to the shared attributes as well as any credential presentations which attest attribute values. The record set also includes the AUDIENCE key.¶
A RP resource record is stored in GNS under records of type "RECLAIM_RP". An RP reference is stored in GNS under the TID. The record format of a RECLAIM_RP is as follows:¶
where:¶
An attribute reference is stored in GNS under records of type "RECLAIM_ATTRIBUTE_REF". An attribute reference is stored in GNS under a label derived from a ticket ID. The reference points to an actual attribute ID. The record format of a RECLAIM_ATTRIBUTE_REF is as follows:¶
where:¶
A re:claimID presentation is stored in GNS under records of type "RECLAIM_PRESENTATION". A presentation is derived from a credential and may contain only a subset of the attestations. The presentation construct is used to support selective disclosure of third party issued credentials. It consists of a type, a flag, a name and data. The record format of a RECLAIM_PRESENTATION is as follows:¶
where:¶
All attribute names in re:claimID are encoded in UTF-8 [RFC3629].¶
The TID in a Ticket SHOULD have at least 256 bits of entropy. The TID could be generated by simply sampling 32 bytes of random data and encoding it using a suitable text encoding compatible with GNS labels such as Base64.¶
The TID MAY be derived using more sophisticated means in order to be able to relax security requirements on the exchange or storage of authorization metadata. One option is to derive the TID using ephemeral Diffie-Hellman. The user would first create an ephemeral key pair and calculate the TID in order to populate the GNS resource records:¶
CreateTid(AUDIENCE_PK): x := rand() ETK := X25519 (x, AUDIENCE_PK) dhs := X25519 (x, G) TID := Base64 (SHA-512 (dhs)) return (TID,ETK)¶
This allows to the user to only transfer the ETK which can in turn be used by the relying party to calculate the ticket identifier (TID) using its private key:¶
CalculateTid(AUDIENCE_SK,ETK): dhs := X25519 (AUDIENCE_SK, G) return TID := Base64 (SHA-512 (dhs))¶
GANA is requested to populate this registry as follows:¶
GANA is requested to amend the "GNUnet Signature Purpose" registry as follows:¶