CycloneDX
Register .well-known URI for TEA
As an alternative, we could register a security.txt field.
The list of security.txt fields is also a registry maintained by IANA.
This seems like a sane thing to do - inline with https://github.com/CycloneDX/transparency-exchange-api/tree/main/discovery#tei-resolution-using-dns.
I think we need a separate issue on Security.txt, because it's such a different approach. The other discovery starts with "I have a product identifier.
The security.txt case is very different as it a way to say "by the way, we have a TEA service". For that to work, there needs to be a way to get product identifiers. It requires further thinking.
So, I don't want to have an API running on the .well-known URI. Should we define a syntax, inspired by security.txt for redirection to another URL?
TEA-baseurl: https://product.example.com/tea/v1/
I don't think simply running a 302 is a good architecture for this. It requires less parsing though.
For security.txt agree we need to define the complete URL to the TEA API Service.
For /.well-known/tei I'd have thought an appropriate HTTP 30x redirect to the TEA API Service would be good enough?
Also @oej - should this actually be /.well-known/tea and not /.well-known/tei??
I think the API is "tea" so let's go for tea. I don't know if there's a best current practice for applying a 302, need to check that. Feels raw, but it will work.
https://www.rfc-editor.org/rfc/rfc8615
I don't find any text against 302 redirects. Good.
https://www.rfc-editor.org/rfc/rfc8615
I don't find any text against 302 redirects. Good.
Some well known URIs even require a 302 redirect. E.g. RFC 6764 (calDAV/cardDAV) states:
Two ".well-known" URIs are registered by this specification for CalDAV and CardDAV services, "caldav" and "carddav" respectively … These URIs point to a resource that the client can use as the initial "context path" for the service they are trying to connect to. The server MUST redirect HTTP requests for that resource to the actual "context path" using one of the available mechanisms provided by HTTP (e.g., using a 301, 303, or 307 response).
The TEA well known URI should probably behave in the same way and require a 301/303/307 redirect to the initial request.