03 September 2024
Attendees
-
Andreas Reich, TrustNXT
-
Andy Rosen, Sequence Key
-
Carly Huitema, U of Guelph
-
Christian Paquin, Microsoft
-
Cullen Miller, Spawning AI
-
David Bigsby, Government of British Columbia
-
Eli Mallon, Aquareum
-
Eric Scouten, Adobe
-
Gavin Peacock, Adobe
-
Jesse Carter, CIRA
-
Jody Booth, Intel
-
Konrad Bleyer-Simon, Global Media Registry
-
Liviu Gheorghe, Adobe
-
Loren Hart, Noosphere Technologies
-
Nigel Earnshaw, BBC
-
Richard W. Kroon, EIDR
-
Scott Perry, Digital Governance Institute
-
Slava Asipenko, Proof
-
Tim Cappalli, Okta
-
Truman Esmond, Partnership for Insurance Information
-
Utkarsh Sharma, Vlinder
Notes
Update on identity assertion 1.0
0'56": Some concerns had been raised privately about the X.509 flavor of the identity assertion and some of the messaging about the dividing line between C2PA claim generator signature as being reserved for hardware and software vendors and CAWG being the primary home for individual and organizational identity.
We discussed the wording regarding claim generator signatures in the C2PA specification, notably §14.4, “Trust Lists,” which says:
In addition to the list of trust anchors provided in the C2PA Trust List, a validator should allow a user to configure additional trust anchor stores, and should provide default options or offer lists maintained by external parties that the user may opt into to populate the validator’s trust anchor store for C2PA signers.
This leaves open the possibility for other trust lists to be chosen by validators and for claim generators with X.509 signing ability to use certs that appear on those trust lists. Eric clarified that the choice of trust lists for validators is more of a market question than a policy question, indicating that Adobe will likely implement the X.509 flavor of the COG identity assertion, but that there is flexibility for different parties' plans and preferences.
| We will hold a ratification vote on the 1.0 version of the spec in the next meeting, scheduled for 9 September 2024. |
Retract HTTPS API?
13'51": Consider retracting PR #168: Define HTTPS API for identity assertion signing services.
In talking with some of the identity providers that are either in this call or otherwise interested in this, what we’re seeing is what they’re offering is not to be the identity assertion signer, but to provide a credential that a third-party, such as our Identity Management Service could access and then aggregate into the verifiable credential that in our case we IMS would then produce. That removes the need for a standard HTTP API surface.
ACTION (âś…): Eric to close PR 168 without merging.
Review PR# 169: Define identity provider
15'12": Review PR #169: Define identity provider.
ACTION (âś…): Eric to merge PR 169.
Proposed change of focus to identity assertion 1.x (VC)
18'29": Eric proposed changing the name of section 8.1 from “W3C verifiable credentials” to “identity aggregation” to better reflect the process of aggregating identity signals from various sources into a single assertion. Adjusting the terminology to “identity aggregation” aims to avoid confusion with the specific technology of W3C Verifiable Credentials and to accurately describe the current practises.
The discussion clarified the role of identity aggregators as trusted entities that bind identity signals to specific assets, highlighting the need for a trust list for these entities.
The group considered the possibility of a future where individuals could sign directly with their own verifiable credentials, acknowledging that the current state does not widely support this yet.
Tim Cappalli suggested adjusting the naming to “identity claims aggregation” and the group agreed to that.
ACTION: Eric to draft a PR to change the name as described.