Endpoint for collection of "receipts" and notifications of RS action in case of extraordinary behavior

[xmlgrrl]

The legal subgroup is still discussing this, but the RO is presumably entitled to collect notifications of when the RS chooses to a) apply extra scrutiny of the requesting side even if the authorization data in the RPT says access is okay, and deny access on its own recognizance or b) recognize that there are "higher authorities" (such as local laws in the jurisdiction) and give access even if the authorization data in the RPT says access isn't okay. An endpoint where the RS could send such notifications seems to make sense. (The AS is one place the RO could nominate for these notifications to be sent.)

Further, this is very similar to the notion -- discussed a bit already -- of an endpoint where consent receipts and other transaction receipts could be collected. Again, the RO's AS might be one natural place where the RO might want to collect these, as some of these artifacts might have even been produced by the AS itself (though very likely not all of them).

Andrew Hughes had nicknamed this the "shoebox" endpoint at IIW XXI because that's where small business owners tend to keep their receipts.

[agropper]

There's another role for a notification endpoint that comes straight from HIPAA but is probably general regardless of jurisdiction: notice that requires acknowledgement. In cases where the RO has a "right of access" to a resource, the law permits the RS to issue a warning to the RO that the client poses a potential risk (e.g.: the client is not listed in a trust registry). The law says that the RS cannot block access but it is allowed to issue a warning.

It's not clear how regulators will interpret this requirement for APIs. Because the situation is unfortunately adversarial, RS will take every opportunity to block access by clients they don't control. If the interpretation is that the RO must actively acknowledge the warning, then the notice mechanism may need to support this capability as part of the Phase 2 flow.

[xmlgrrl]

Andi points out that the RS could itself have an endpoint from which audit-type information could be requested. In other words, "notification" information could be delivered the other way around.

Is this relevant to Policy Manager-type conversations? Potentially yes, particularly if we adopt the "option 2" scope where the RS-RO communications get standardized.

[agropper]

The US health care use case is arguably the design goal for this. The API Task Force recommended and the advisory group later approved that an RS could NOT deny an authorized request if they did not like the client BUT they could notify the patient (as RO) with a "black box warning" about the client. The RO could choose to override the warning and the RS would have to allow access. The only significant departure from this, per the API Task Force, are security issues such as a Denial of Service attack by a client. In that case, the RS is allowed to just say NO. This obviously does not mean that a Notification endpoint should be part of UMA but it says that an audit-type endpoint at the RS would not deal with this issue. This also means that the Notification flow needs to be bi-directional so that the RO can override the RS warning. As for the Policy Manager issue, it is true that the PM could set a Notification Endpoint during the Resource Registration and then monitor it to enable the patient response. This implies a PM can listen as well as talk. - Adrian

…

On Thu, Sep 24, 2020 at 11:18 AM Eve Maler ***@***.***> wrote: Andi points out that the RS could itself have an endpoint from which audit-type information could be requested. In other words, "notification" information could be delivered the other way around. Is this relevant to Policy Manager-type conversations? Potentially yes, particularly if we adopt the "option 2" scope where the RS-RO communications get standardized. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#246 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABB4YNFUCDR6J6IG35DPKDSHNPMXANCNFSM4B4NTILA> .