Clarify request_context normative language

[PieterKas]

From #253

@gffletch and @tulshi opened a discussion about the normative language used regarding the request_detailt and rctx claim. This was orthogonal to the original issue being adressed. to avoid having a PR open for a long time when the issue being raised is not related to the issue in the PR, this issue wass created instead. Screenshot of discussion below:

[PieterKas]

Regarding the discussion on this I believe there are two orthogonal discussion points:

@gffletch - you raised the question on whether the worklod idenitifier normative langugage needs to be stronger. Our latest language on authentication is that it is a MUST, sso that information has to be available. However, rctx is an optional claim, and so, any MUST (and arguably the SHOULD as well) is conditional on rctx ebing included. We may want to state that conditionality explicitly. e.g. if we decide it is a MUST, we need langugage like, "if the rctx claim is included, the workload identifier MUST be included as the req_wl claim).

@tulshi - I think the question you raise is separate from what George raised. I agree with your perspective that request_context is one of the inputs, but should not be the only input to determining rctx content. Enriching that with out-of-band information drawn from some back-end management service seems likely and plausible. If we remove the SHOULD, we may want to add langugage that suggest backend enrichment may be an option.

[gffletch]

I think from an authorization perspective, knowing the workload that requested the transaction token is likely very important. As in, "I don't accept transaction tokens unless they were requested by these N workloads". That doesn't make it a MUST, but maybe there is more guidance we should add in that vein?

We already of text that says that the TTS is authoritative for the authorization of TraTs within the trust domain.

Maybe something like...

The TTS is a critical component of the enablement of the authorization model in a given deployment. To that end, the TTS is responsible to ensuring any issued transaction tokens have all the necessary claims to allow downstream systems to implement the required authorization policy. Authorization models and deployment implementation details are out of scope for this specification.

[PieterKas]

The TTS is a critical component of the enablement of the authorization model in a given deployment. To that end, the TTS is responsible to ensuring any issued transaction tokens have all the necessary claims to allow downstream systems to implement the required authorization policy.

This feels unnecessary. If the TTS does not do this, authorisation will fail and it gets fixed as a configuration update. Including language like this spirals into "how does the TTS know what all the authorisation condition are?".

There are two thing to add:

Clarify the conditionality of the normative language: e.g. If the rctx claim is included, the workload identifier MUST be included as the req_wl claim.
Clarify the ability of the TTS to enrich this information based on backend enrichment.

[gffletch]

Regarding the req_wl I don’t know that that claim MUST come from the rctx. Since client authentication is required, the TTS could specify the req_wl from the client authentication even if no rctx is specified.

While I agree that from a pure spec perspective, other guidance isn’t required, I do worry about developers not understanding what the purpose or intent of specific claims are and how those relate to the security of the deployment. While we can’t guarantee secure deployments via spec writing, I do think we should provide reasonable guidance. Maybe this could be in a security consideration?

Generally, what goes into the rctx and what claims that object contains is up to the TTS regardless of what was supplied to the TTS. If that isn’t clear, then that’s the first think to clarify.

[PieterKas]

Regarding the req_wl I don’t know that that claim MUST come from the rctx. Since client authentication is required, the TTS could specify the req_wl from the client authentication even if no rctx is specified.

I am not sure I follow - are you saying the req_wl is not expected to be included in rctx? The examples all use it as included in the rctx and the text defines req_wl in the context of rctx.

[gffletch]

Sorry, that is my fault. I was thinking that the req_wl doesn't need to be specified in request details object. I'm sorry for the confusion.

Yes, the req_wl should be available in the rctx object regardless of how the TTS determines the value. :)