-
-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Register .well-known URI for TEA #30
Comments
As an alternative, we could register a The list of |
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. |
Created #67 for security.txt so this issue is focused on .well-known |
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?
I don't think simply running a 302 is a good architecture for this. It requires less parsing though. |
For For Also @oej - should this actually be |
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. |
Some well known URIs even require a 302 redirect. E.g. RFC 6764 (calDAV/cardDAV) states:
The TEA well known URI should probably behave in the same way and require a 301/303/307 redirect to the initial request. |
The IANA maintains a registry of .well-known URI's
The text was updated successfully, but these errors were encountered: