Interim 2023-05-15
Topics:
Hackathon:
Ray is concerned that DiDs won't be embraced and standardized, and so we
won't be able to rely on it. Wouldn't pURL be better to identify
'things'?
Yogesh believes it will be adopted by W3C for verified credentials.
Ray remains concerned that since it's not an IETF item we are not
sufficiently in control of it to make it such an important dependency.
Ray asked whether PURLs are better suited for our purpose.
Jon responded whether the PURLs aren't used for a different purpose -
for identifying software packages rather than for identifying entities.
Dick: When I worked on the NTIA SBOM work, you need 3 data elements:
supplier name, product name, and a version. PURL was discussed but
wasn't really established containing the minimal elements. CISA
announced their software attestation form. There is no requirement for
PURL in that document.
Charlie: There is no guidance from NTIA on what to use. Other groups
have decided to declare PURL as the "winner" - probably prematurely
since PURL does not work with proprietary software. I don't think this
topic is solved.
Roy: Added extra info to what Charlie said about the build system. It
will be a while to conclude the discussions about persistent
identifiers.
Charlie: PURL is only good if you can get the build kit on the web
somewhere.
Dick: Charlie's observations match my observations. There are three
minimal pieces of information for identifying software.
Roy: Why is this?
Dick: Vendor's want to be in charge of their own software naming. By
using the three elements, you can accomplish uniqueness.
Ray: I wouldn't expect vendor's to change the name of their software. We
are not constrained to use a single string - we can also use a JSON
object to describe software. Has something been written up regarding the
concerns about PURL etc?
Charlie: It is not written up.
Hannes: The PURL topic is different from DID.
Charlie: I think we have to work with the imperfect solutions available.
Roy: For DID we have to find out on what method to focus on. PURL is
independent from DID.
Orie: In the context of identifiers I have implemented RFC 9162 and I
was wondering whether we have investigated re-using this. Here is the
link:
https://datatracker.ietf.org/doc/html/rfc9162#name-urn-sub-namespace-for-trans
The IETF already has a URN namespace reserved for "transparency"
Hannes asking Jon & Orie
Orie: I have been using DID for the issuer field. You need a policy for
the issuer and kid. I have been implementing this.
DID resolution with reog:
https://github.com/transmute-industries/vc-opa/blob/main/did/resolve.rego
It is not difficult if you use JSON Web Keys. Registration policies
should work with the identity system that transparency service uses, but
I think we should cover at least 1 scenario that supports authenticating
the issuer.
It is not our business to say what policy language to use. We have a
responsibility to document the issuers for signed statement. Same for
the other side (transparency service), we have to make the identity
ecosystem compatible between the two parties. You could mix.
Roy: Is a DID method that wraps X.509 in a DID the right approach?
Orie: I don't know. Someone should sit down to use X.509 in DID for
SCITT?
Roy will look for a document that describes what they have been doing
with X.509/DID.
Dick: Even a valid party can become an invalid signature. It is not
enough that the party is legimitate but you still have to find out
whether the key is still valid. We have been trying to address this with
the first use case. So, the revocation status has to be checked.
Roy: With SCITT we have the possibility to issue new statements.
Dick: Agree. We need to be more granular.
Roy: The 99% case should be a negative endorsement rather than
certificate revocation.
Discussion about the different lifetime of signing keys.
Orie: How to use DIDs with certificates it not well defined. Here is a
tutorial:
https://github.com/transmute-industries/openssl-did-web-tutorial
Charlie points out that software does not go away but companies do. We
have to think about identity management.
Hannes points to the NIST SP 800-63 about identity management:
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63-3.pdf