It would be nice if the first-party caveats added to discharge macaroons were documented and tied to the requested version
Bug #1814563 reported by
Martin Hilton
This bug affects 1 person
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| Canonical SSO provider |
Triaged
|
High
|
Unassigned | ||
Bug Description
When creating a discharge macaroon for a third-party caveat a number of first-party caveats are added to the discharge macaroon, these are used to transfer information to the target service.
The safest thing for a target service to do with a caveat it doesn't understand is not verify the macaroons, as it may be violating an additional constraint on the macaroon that it does not understand.
With that in mind it would be nice if the first-party caveats that might be added to a discharge macaroon were fixed to a documented set for the requested caveat ID version. That way a target service cannot inadvertently ignore a caveat SSO intended on the macaroon.
Revision history for this message
| Colin Watson (cjwatson) wrote | #1 |
| Changed in canonical-identity-provider: | |
| status: | New → Triaged |
| importance: | Undecided → High |
To post a comment you must log in.
This is effectively an API guarantee which we ought to make to avoid inadvertently breaking other services that integrate with SSO.
While we're here, we should document the third-party caveat ID requirements (encryption, padding, etc.).