Possible to audit host's compliance in giving access based on a legitimate active permission from the AM?

[xmlgrrl]

Currently, the AM is not fully a "policy decision point" and the host is not merely a "policy enforcement point" because the AM tells the host what the active permissions are, and the host makes a judgment about whether one of them matches what the requester is trying to do. The AM must trust (read: is vulnerable to) a host that chooses to give access in a manner that doesn't match what the AM tells it.

We could get some measure of auditing / non-repudiation if we give the host the option (or require it) to tell the AM what type of permission it's actually looking for when it asks for token status. There are a few ways to do this:

• The host could ask for full token status, without supplying the permission it's "hoping" to see (current situation, requires a lot of AM-host trust)
• The host could ask for full token status, supplying the permission it's "hoping" to see (semantics: it intends to give access to that requester for that resource set with that scope unless the AM's response doesn't contain the hoped-for permission)
• The host could ask for a selected token status, supplying the permission it's "hoping" to see and getting back what amounts to a filtered token status showing if there's a match (semantics: it intends to give access to that requester for that resource set with that scope unless the AM's response is empty)
• The host could ask for a yes/no policy decision, supplying the permission it's "hoping" to see and getting back what amounts to boolean (semantics: it intends to give access to that requester for that resource set with that scope if the AM's response is positive)

This issue affects Sections 3.1.5 and 3.3. It also may affect the Trust Model if we strength the amount of "technical trust" the AM operator can have in the host operator around this.

[findthomas]

From UMA meeting minutes: http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2011-11-03

Issue #24: Possible to audit host's compliance in giving access based on a legitimate active permission from the AM?

• Paul: Short answer: no.

• Paul: Longer answer: AM provides advice to host, and is not direct party to the interaction between requester and host.

• Paul takes AI to comment on ticket in GitHub.

[findthomas]

From UMA Meeting minutes: http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2011-10-27

We discussed issue #24. George points out that this whole proposition only makes sense with our current opaque-token option, since if the host received a structured token and validated and looked at it fully locally, the AM wouldn't have a chance to know the host's intent. A back-channel call to inform the AM of the host's intent would be antithetical to the reason why you'd want to use structured tokens in the first place: performance. However, the AM would still have an audit trail because it minted and signed the token in that case. And the host will have ecosystem pressures against it if it does provide access inappropriately.

Maybe, given the fact that we still cater to the opaque-token case, we could make it an optional property that the host can supply in asking for token status from the AM. They'd have to supply a scope (sort of a permission template), not an actual permission. What the AM would supply in return is an actual permission.

Let's give this a try in the spec.

[findthomas]

Assuming there is some degree of trust between the Host and AM (eg. under some Trust Framework), would it be possible for the Host to always provide the AM with a "courtesy report" about the accesses at he Host that has occurred related to a given token (issued by the AM).

In this way both the Host and AM has a synchronized log about: (a) Every token issued by the AM (relating to resource at the Host), and (b) the actual access event where the Requester presented a token to the Host.

[xmlgrrl]

Note that this issue relates, slightly, to issue #14. They should ideally be considered together.

[xmlgrrl]

This is related to issue #63 and they should be considered together.

[xmlgrrl]

Backlogging this.