[Openid-specs-heart] Confidentiality and sensitivity scopes: needs a bit more discussion and an example

[Eve Maler]

Since SHOULD is a strong direction, I'd rather state the details of the conditions for disobeying the SHOULD. I mean, should we be advising that RS's consider not registering resources with these scopes if the data isn't tagged and friable (and why MUST it advertise the ability if it then can't act on it later)? A bit of discussion seems warranted.

My main reason for writing about this, though, is that the "positive action for an absence of a scope in a token" seems buried in a lot of words, and the implications may be missed by readers. For clarity, a bit tighter wording would help (from "SHOULD assume that the client does not have access to that information and SHOULD apply appropriate filters to the data, where possible" to something like "SHOULD [if possible/with caveats...] filter data that has such a scope available in cases where the scope was not granted").

It would also be helpful to supply at least one logical example -- or even better, an example and its converse. I also wonder if providing examples in the UMA+FHIR spec, despite its pure reference out to the OAuth+FHIR spec when it comes to confidentiality and sensitivity codes, would be valuable, because the process in the UMA case involves resource registration with scopes.

Eve (from my iPad)

> On Jun 10, 2017, at 4:55 AM, Justin Richer <jricher at mit.edu> wrote:
> 
> We don't want to presume that all data is tagged and friable. That was a big debate earlier on in the group and we decided, and I still believe, that that kind of data tagging is out of scope for here. That's why it says "where possible". If it's not possible to filter that data, you're not required to.
> 
>  -- Justin
> 
>> On 6/9/2017 4:52 PM, Eve Maler wrote:
>> I'm thinking that it wouldn't hurt to have a bit more disquisition on this topic in the OAuth+FHIR spec. :-)
>> 
>> Here's what the spec says:
>> 
>> "This specification makes no assumptions regarding the ability of resource servers to tag and filter data. A resource server that is capable of filtering information MUST advertise this capability through the use of these scopes. Resource servers SHOULD use this access information to filter out data being returned to a client, if possible. If an access token does not contain a given confidentiality or sensitivity marker, the resource server SHOULD assume that the client does not have access to that information and SHOULD apply appropriate filters to the data, where possible."
>> 
>> Maybe a more direct way to state the last sentence is that the RS SHOULD filter data with such a scope (do we even need to say "where possible"? what are the conditions for that?) as long as the scope was not granted. And then we should give an example, so that the consequences are brought home to the reader. Maybe even give the converse example too.
>> Eve Maler
>> ForgeRock Office of the CTO | VP Innovation & Emerging Technology
>> Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
>> 
>> 
>> 
>> _______________________________________________
>> Openid-specs-heart mailing list
>> Openid-specs-heart at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-heart
> 
> _______________________________________________
> Openid-specs-heart mailing list
> Openid-specs-heart at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-heart
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20170610/903a4ff8/attachment.html>