Conversation
| credentials for the selected TEA service, such as an API key) and have the platform | ||
| access the required artefacts in a highly automated fashion. Those credentials are | ||
| provisioned separately and are not embedded in the TEI. | ||
|
|
There was a problem hiding this comment.
This branch is based on current main (still URN). I’d like to keep this PR’s wording TEI-neutral and leave the URN→URL migration to #261 so we don’t mix scopes — does that work for you?
|
|
||
| How this is communicated to the client users is implementation specific. | ||
| the discovery endpoint fails with a 5xx error code, or TLS certificate validation fails, | ||
| the client MUST select the next untried endpoint that supports a compatible API |
There was a problem hiding this comment.
MUST is not the right word, we need to use SHALL (ISO vocabulary).
| ### TLS Encryption | ||
|
|
||
| The .well-known endpoint must only be available via HTTPS. Using unencrypted HTTP is not valid. | ||
| The `.well-known` endpoint must only be available via HTTPS. Using unencrypted HTTP is not |
There was a problem hiding this comment.
remaining must -> SHELL here
| the client SHALL select the next untried endpoint that supports a compatible API | ||
| version, if one is available. While doing so the client SHOULD preserve the priority | ||
| order if provided (from highest to lowest priority). Each failover connection is subject | ||
| to the same TLS verification requirement. Clients SHALL limit the total number of |
There was a problem hiding this comment.
SHALL -> SHOULD here, SHALL needs more substance
| A protected TEA resource endpoint (excluding `/token`) SHALL respond to a request without | ||
| valid authentication with `401 Unauthorized` and a `WWW-Authenticate: Bearer` challenge. | ||
| When that challenge contains `error="invalid_token"`, the client MAY obtain a replacement | ||
| access token from the same service and retry the original request once (RFC 6750 |
There was a problem hiding this comment.
Claude tells me RFC citation is wrong here, as it defines error codes, not retry behaviour.
There was a problem hiding this comment.
Agreed the citation should not imply RFC 6750 specifies our one-shot policy. section 3.1 does define invalid_token and allows MAY request a new token and retry; the “once / same service / not refresh” limits are TEA. Updated the sentence accordingly.
| Clients must pick any one of the endpoints listed in the `.well-known/tea` json | ||
| response. The client MUST pick an endpoint with the at least one version that is | ||
| supported by the client is using. The client MUST prioritize endpoints with the | ||
| response. The client SHALL pick an endpoint with the at least one version that is |
There was a problem hiding this comment.
Line is garbled "with the at least..."
|
Thanks — pushed a follow-up addressing:
|
|
I believe it's good now, should be merged after #261. |
|
#261 is merged so this needs to be updated for merge :-) |
Clarify credentials vs TEI, TLS verification, Bearer invalid_token recovery, and that auth failures are not "no updates". Tighten version-compatible failover and bounded discovery retries. Fixes CycloneDX#275. Signed-off-by: Mehrn0ush <mehrnoush.vaseghi@gmail.com>
Signed-off-by: Mehrn0ush <mehrnoush.vaseghi@gmail.com>
Replace leftover must with shall, fix garbled endpoint selection prose, soften discovery attempt bound to SHOULD, and attribute RFC 6750 section 3.1 to invalid_token only (retry remains TEA MAY). Signed-off-by: Mehrn0ush <mehrnoush.vaseghi@gmail.com>
e7529ad to
84c193e
Compare
|
done |
3 participants
Summary
discovery/readme.mdwith the feat: token exchange endpoint and documentation #258 auth model: separately provisioned credentials (e.g. API key) →/token, not credentials in the TEI401/invalid_tokenone-shot recovery (MAY), no failover solely on401/403, and that auth failures MUST NOT be reported as “no updates”Closes Auth issues #275.
Notes