[Openid-specs-heart] Sum it up

[Eve Maler]

Adrian and I were chatting off-list, and he asked me to share here more
detail that I gave him about how the AS stays out of passing attributes to
the RS. Here's what I said:

"The RqP might reveal an attribute to the RS, but if they do, it's entirely
in the context of a local (non-UMA) authorization process, and does not go
through the AS. If the AS knows the RqP has a valid medical license in the
state of MA, the AS doesn't reveal it to the RS. And if the RS comes to
find out that the RqP has a valid medical license in the state of MA, the
RS didn't learn it from the AS.

(Note that this is all true because we're assuming that the default
"bearer" UMA token profile is in use. If an alternate token profile were in
use that changed the responsibilities of the AS, namely letting it just
collect the RqP's attributes and stick them in the RPT, vs. evaluating out
[Alice's] policies against them and putting the resulting permissions in
the RPT, then the RS would indeed see the attributes. But that would change
a LOT of things, and I'm not currently advising it.)"

FWIW,


*Eve Maler*ForgeRock Office of the CTO | VP Innovation & Emerging Technology
Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
Join our ForgeRock.org OpenUMA <http://forgerock.org/openuma/> community!

On Tue, Jan 5, 2016 at 9:47 PM, Eve Maler <eve.maler at forgerock.com> wrote:

> Hi guys-- I'm following along as best I can on a busy day/night, so I hope
> my contribution for the moment will be additive and not missing the point...
>
>    - Adrian's points about ensuring fairness to Alice around the hospital
>    trying to block information access are very well taken.
>
>
>    - I don't quite see why an individually controlled AS is strictly
>    required, though I see how it can help at the margin. Certainly the RS has
>    business reasons (risk mitigation and so on) why it favors more blocking;
>    if the AS is in business to serve Alice it will already work in her favor,
>    but more business-model pressure in that direction is good.
>
>
>    - Note that the default way that UMA works doesn't involve the AS
>    passing any of the requesting party's attributes along to the RS; it just
>    passes calculated "permissions" in the access token for the RS to inspect
>    before judging whether to let the requesting party and their client app in.
>    (An alternate UMA token profile could arrange for passing attributes
>    instead, but on balance I'd probably not advise that we go in that
>    direction in our profiling...)
>
>
>    - However, UMA does say
>    <https://docs.kantarainitiative.org/uma/draft-uma-core-v1_0_1.html#give-access>
>    "The resource server MAY apply additional authorization controls when
>    determining how to respond" when the access token contains sufficient
>    permissions for the requesting party to get access. Obviously, this is
>    where potentially pernicious behavior like delaying access for 72 hours
>    could creep in.
>
>
>    - The UMA group has been working on draft model clauses that could
>    form the basis for legal agreements, consent receipts, etc. We've been
>    discussing what to do about model clauses that ensure the RS *never*
>    gives access when the access token contains insufficient permissions, and
>    offering model clauses that say the RS *has to* notify the RO somehow
>    whenever it blocks immediate access when the access token contains
>    sufficient permissions. (Accounting of disclosures, anyone?)
>
>
>    - This could be an interesting element for us to profile, *if* we
>    consider this to be in scope -- iffy because it's in business model-land.
>
>
>
> *Eve Maler*ForgeRock Office of the CTO | VP Innovation & Emerging
> Technology
> Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
> Join our ForgeRock.org OpenUMA <http://forgerock.org/openuma/> community!
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160107/2243a890/attachment-0001.html>