Hi Andy, On 21.06.24 16:44, Andrew Newton (andy) wrote:
On 6/21/24 09:32, kowa...@denic.de wrote:If you are saying that this draft is the result of experience with rfc 9537, I 100% agree. I did not think of it until after realizing that, with few exceptions, the redaction methods in 9537 can only apply to strings.Hi Andy,Taking into account that this proposal is a result of considerations on rfc9537 I think this draft takes the issue too simplified or easy, just by removing the difficult part of the problem in rfc9537.
I would say otherwise, that rfc 9537 is indeed not very specific what some of redaction methods mean if the value is not string (as your draft mentioned - what is the empty value of boolean or number) and maybe rfc 9537 could have been more specific about nonsense or impossible combinations, however in my opinion rfc 9537 is enough to describe all real life combinations of redaction, so in the end the rest is about handling of the cases which will practically never happen. So you may say the client won't be wrong no matter what the handling would be.
An errata to rfc 9537 may be helpful make the life easier, indeed however I wouldn't name rfc 9537 not possible to implement justifying a brand new approach.
My argument was indeed to still cover for placeholder values in order to handle not redaction aware clients, accounting for no content negotiation possibility for the server to know if the client would understand the extension. I think in practice we might see redaction by replacement value misused for this purpose. This would be rather only happening to the common fields, but removal might be equally happening for other kind of fields, like events.Actually it dictates allowed methods how redaction is done by the server, practically eliminating the possibilities foreseen in rfc9537 which lead to removal of properties, objects or array elements (mainly "Redaction by Removal" and one mode of "Redaction by Replacement Value"). If you'd remove these methods from rfc9537, you'd actually fix the issues with prePath as well because prePath would never occur.If redaction by removal was instead redaction by placeholder, then the items being redacted could be identified by JSONPath (assuming JSONPath is usable). I believe you proposed placeholder values but the 9537 authors rejected it.
I think lack of redaction by removal would be more of an issue in your proposed approach.The group consensus was however that these methods exist and are in use by the servers, so not taking them into account in rfc9537 would have too much of an implication on the servers. This would result in servers still doing the same thing (ergo removing properties, objects or array elements) and not having a way to signal it.I am struggling to understand the logic that a server has the adequate knowledge to redact by empty value or redact by partial value but cannot substitute values for keys.
postPath does not pose such an issue, because even if more than one path is selected it is clear which elements of the response have been redacted any why. If an overlap happens the client can display both reasons fo the redaction.Overlaps are problematic to clients (and users) when they are signaled by multiple redaction methods. I cannot think of a compelling reason why they should be allowed.
The starting point is the server policy. If the server would have overlapping policies, say: policy 1: remove all handle-IDs due to security, policy 2: remove all handles of person type, then those would overlap.
So either the server would have to handle that and build redaction description of overlapping objects which cover those 2 policies, or it can inform the client which can handle it like much better in terms of display to the user.
A feature that your proposal adds is a possibility to mark exactly which part of partial redaction have been replaced. It didn't appear to me as a goal for rfc9537 to have information specific to that extend, especially in an unstructured data. The clients processing such response may still mark the whole field as redacted leaving the interpretation to the user. If this feature is deemed to be important it can be still added on top of rfc953, using a method you've proposed or any other suitable mean.Being able to differentiate the parts of a string that are redacted is particularly acute when it comes to things like unstructured postal addresses (see section 4.1 of my draft) and tel URIs (see section 2.2 of my draft).
as mentioned, this may be handled as extension of rfc9537 if it is important.
Kind Regards, Pawel
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
