[OAUTH-WG] OAuth Digital Credential Status Attestations

Orie Steele <orie@transmute.industries> Wed, 17 January 2024 18:07 UTC

Return-Path: <orie@transmute.industries>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80F1DC15108C for <oauth@ietfa.amsl.com>; Wed, 17 Jan 2024 10:07:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.085
X-Spam-Level:
X-Spam-Status: No, score=-7.085 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, T_REMOTE_IMAGE=0.01, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=transmute.industries
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w37ENguKG5n0 for <oauth@ietfa.amsl.com>; Wed, 17 Jan 2024 10:07:10 -0800 (PST)
Received: from mail-pj1-x102a.google.com (mail-pj1-x102a.google.com [IPv6:2607:f8b0:4864:20::102a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9D48C14F71D for <oauth@ietf.org>; Wed, 17 Jan 2024 10:07:10 -0800 (PST)
Received: by mail-pj1-x102a.google.com with SMTP id 98e67ed59e1d1-28e718874e1so1571891a91.0 for <oauth@ietf.org>; Wed, 17 Jan 2024 10:07:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=transmute.industries; s=google; t=1705514830; x=1706119630; darn=ietf.org; h=cc:to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=pRf+2Rg/q3xwaWga2QgiSLyfa3oOl2SAunvA+Kd6/0M=; b=bAexj8fYyijNJawNi0LK+45vQEqY0h4yB4c6bd2PNft2tVzdbzn8DQpXDjR3m7kCcS aieCaaltGItMa7tdIGXh/+TX9XoWXwJR2jajtL4Xu0cyz92siK7REOT9OSa/bzSBx+iI izsT6MXwaGGi/L2tZ4QTBRyPv7Urlvso1kqlGkxuOrZINGID2guVroWxWAoTobuxssOR bXeXdWukdef9i82YWX4P9lITj2xoQ9P8FnFekoZruZIkbVTG6+/GIA61vyF/JL7RAnuW W9E97VOJ/OMTv8cZMLAniLEjwZrFWcsPf8Pg6Thqhcagci4zUv/qpudRQsHteNmhv9oZ uN9w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705514830; x=1706119630; h=cc:to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=pRf+2Rg/q3xwaWga2QgiSLyfa3oOl2SAunvA+Kd6/0M=; b=NJo/QfPEzYwaJAZIAq+jkaXDfY1lizj9kCLt6hFzBCliYHl4LD1jP4dejzIru3ALuP 4NIpavqU5UVXuUgoIprOSvp5dhU+nzmz5rOdVjSw6cN6cK7sS6o5jE/btaHcFyuneZRo qx53VY5bfi51POXF0uxIzD8YZLDNJKo24J/Lj76rswjaMHYdk+pzyn7DmnPhfCAyb6sE oO+d+xvWsxMHtyIC486uUXchcVLlROSXNhEWBD4xvI3xjgJYTuqnoaC+sQDQ3a/A4z3G BoCxhaK9M2MWHrYu0uwAL0ADlgctuNiA5DFRHX/oM/IRRq4Ct/p1fKCpPBNP686XpJCy 7GNw==
X-Gm-Message-State: AOJu0Yzn7WUONwJV0Z4hcjQgsnu9sj4k6COBrqAH6FGVCpgokOsqEwEg EWkwVGjDhEr/pBxnsCVpSaUHoezmwU2Z5nwtSpG7vMQvJFD8/SF4t2CDNXSG1UY=
X-Google-Smtp-Source: AGHT+IHbs+TjSk4tYs07AxwdumxFqiEuItYDzVuCx++eTVxNOxW/1Lpc2twBKiqjo6yebWzEQbBsnJ6OrHd/lfVFdVU=
X-Received: by 2002:a17:90b:109:b0:28f:feed:90f6 with SMTP id p9-20020a17090b010900b0028ffeed90f6mr748919pjz.26.1705514830098; Wed, 17 Jan 2024 10:07:10 -0800 (PST)
MIME-Version: 1.0
From: Orie Steele <orie@transmute.industries>
Date: Wed, 17 Jan 2024 12:06:59 -0600
Message-ID: <CAN8C-_+5mSFAion-e4Ta6AZLVGadr7cdSWjw-UpnBvH9Z98ohw@mail.gmail.com>
To: spice@ietf.org
Cc: oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000009b8e3d060f281d50"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/HjgVOG7CHE6024gsFXUyWhsCBmw>
Subject: [OAUTH-WG] OAuth Digital Credential Status Attestations
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Jan 2024 18:07:14 -0000

Hello Digital Credential Enthusiasts,

See:
https://peppelinux.github.io/draft-demarco-status-attestations/draft-demarco-status-attestations.html

Note the use of the term digital credential, and the alignment to CWT based
credentials and CWT based credential status lists.

As a quick summary of the editors draft above:

It is basically a refresh-token-like approach to dynamic state, where the
holder retrieves updated state from the issuer at regular intervals, and
can then present that dynamic state directly to the verifier.

This eliminates the herd privacy and phone home issues associated with W3C
Bitstring Status Lists.

And it informs the holder of dynamic state, so the digital wallet can
provide a better user experience.

However, an issuer (government or ngo) could use the interval of requesting
dynamic state, to track the holder... so the guidance from
https://datatracker.ietf.org/doc/draft-steele-spice-oblivious-credential-state/

Is also relevant to this draft.

I also learned that
https://datatracker.ietf.org/doc/draft-ietf-oauth-sd-jwt-vc/

Has defined a new property for expressing "Verifiable Credential" "type"
`vct`, which is different from how W3C defines credential types.

W3C uses the expanded IRI for the graph node type, based on the JSON-LD
context.

For example with:

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "id": "http://university.example/credentials/1872",
  "type": ["VerifiableCredential", "ExampleAlumniCredential"],
  ...
}

The credential type in RDF becomes "
https://www.w3.org/ns/credentials/examples#ExampleAlumniCredential"

Which is different from "ExampleAlumniCredential" in JSON... More evidence
that RDF leads to developer confusion regarding safe typing.

The OAuth solution does not have this confusing issue, they set the type
explicitly:

{
 "vct": "https://credentials.example.com/identity_credential",
 "given_name": "John",
 "family_name": "Doe",
 "email": "johndoe@example.com",
 "phone_number": "+1-202-555-0101",
 "address": {
   "street_address": "123 Main St",
   "locality": "Anytown",
   "region": "Anystate",
   "country": "US"
 },
 "birthdate": "1940-01-01",
 "is_over_18": true,
 "is_over_21": true,
 "is_over_65": true,
 "status": {
    "status_attestation": {
        "credential_hash_alg": "S256",
    }
 }
}

Regards,

OS

-- 


ORIE STEELE
Chief Technology Officer
www.transmute.industries

<https://transmute.industries>