Closed achamayou closed 5 months ago
SCITT has now moved on from did:web, and instead specifies something much closer to openid-configuration, and SCITT/application-specific that does make sense in a generic CCF context:
2.1.1. Transparency Configuration
Authentication SHOULD NOT be implemented for this endpoint. This
endpoint is used to discovery the capabilites of a transparency
service implementing this specification.
Request:
GET /.well-known/transparency-configuration HTTP/1.1
Host: transparency.example
Accept: application/json
Response:
Birkholz, et al. Expires 5 September 2024 [Page 5]
Internet-Draft SCRAPI March 2024
HTTP/1.1 200 Ok
Content-Type: application/json
{
"issuer": "https://transparency.example",
"registration_endpoint": "https://transparency.example/entries",
"nonce_endpoint": "https://transparency.example/nonce",
"registration_policy": \
"https://transparency.example\
/statements/urn:ietf:params:scitt:statement\
:sha-256:base64url:5i6UeRzg1...qnGmr1o",
"supported_signature_algorithms": ["ES256"],
"jwks": {
"keys": [
{
"kid": "urn:ietf:params:oauth:\
jwk-thumbprint:sha-256:DgyowWs04gfVRim5i1WlQ-HFFFKI6Ltqulj1rXPagRo",
"alg": "ES256",
"use": "sig",
"kty": "EC",
"crv": "P-256",
"x": "p-kZ4uOASt9IjQRTrWikGnlbGb-z3LU1ltwRjZaOS9w",
"y": "ymXE1yltJPXgjQSRe9NweN3TLlSUALYZTzy83NVfdg0"
},
{
"kid": "urn:ietf:params:oauth:\
jwk-thumbprint:sha-256:4Fzx5HO1W0ob9CZNc3RJx28Ixpgy9JAFM8jyXKW0ClE",
"alg": "HPKE-Base-P256-SHA256-AES128GCM",
"use": "enc",
"kty": "EC",
"crv": "P-256",
"x": "Vreuil95vzR6ixutgBBf2ota-rj97MvKfuJWB4qqp5w",
"y": "NkUTeaoNlLRRsVRxHGDA-RsA0ex2tSpcd3G-4SmKXbs"
}
]
}
}
FYI @ivarprudnikov @andpiccione @vimauro
See https://github.com/microsoft/scitt-ccf-ledger/issues/53 and https://github.com/microsoft/scitt-ccf-ledger/issues/88 for history.
This information is exposed now in the JSON & C++ receipts as "service_endorsements": https://github.com/microsoft/CCF/blob/b78c1d00133d3c2979d8f11ec10c34345e6bb3b4/include/ccf/receipt.h#L30, but not in a did/jwk-friendly format.
This is partially implemented in the SCITT ledger now, but would be useful to bring back to CCF generally, for any user who wants a service identity history in a different format. To be defined and implemented is the way key validity ranges are indicated, perhaps by defining additional possible values for
use
, such as"sig:from:2.54:to:5.7869"
, or by using a new field in the key.