[Openid-specs-heart] HEART Profiles - Authorization Server OAuth / UMA Clarification

Tue Dec 8 19:53:22 UTC 2015

I apologize for only sending this now. The following sentence was not in
the version on which I sent comments to Justin and Sarah on November 23.

*HEART UMA Sec 2
<http://openid.bitbucket.org/HEART/openid-heart-uma.html#Tokens>: "It is
RECOMMENDED that the PAT use a user-delegated mechanism for issuance and
the AAT use a non-delegated method for issuance."*

I believe this incorrectly specifies a critical profile detail, as well as
using terms that are not very well-defined.

*Minor issue in the HEART UMA profile and tackling the terminology issue
for techies and nontechies alike*

First, the minor issue: As we discussed briefly on the call yesterday,
"user-delegated" and "non-delegated" appear to correspond to what have been
colloquially called "three-legged" and "two-legged" in the OAuth community.

In plain English, the first one means that a human delegates to a client
application the right to access some protected resource. The second one
means that the client gains access to the protected resource autonomously,
on its own recognizance. (UMA would look at the larger context of the "NPE"
that the app represents -- in other words, it would note that there
actually *is* a resource owner and it's not a human being.)

It would be much clearer to identify the acceptable OAuth "grant
<http://tools.ietf.org/html/rfc6749#section-4>" flows in each case;
"non-delegated" translates uniquely to the OAuth client credentials
<http://tools.ietf.org/html/rfc6749#section-4> grant flow.

*Major issue in the HEART UMA profile*

Now the major issue: The "non-delegated" [client credentials]
recommendation suggested here for the AAT would be incorrect for solving
any use case where the requesting party is a human being ("natural
person"). I believe you're suggesting an experimental usage of UMA that was
not intended by the original spec:

*UMA Core Sec 1.3.2:
<https://docs.kantarainitiative.org/uma/draft-uma-core-v1_0_1.html#authorization-api>
"An AAT binds a requesting party, a client being used by that party, and an
authorization server that protects resources this client is seeking access
to on this requesting party's behalf. .... The issuance of an AAT
represents the approval of this requesting party for this client to engage
with this authorization server to supply claims, ask for authorization, and
perform any other tasks needed for obtaining authorization for access to
resources at all resource servers that use this authorization server.**"*

I'm concerned that an implementation that treats the client as
autonomous/NPE for AAT purposes, and then switches to a "human requesting
party" interpretation later on during trust elevation, may have anomalous
behavior when it comes to overall management of the requesting party's
identity compared to properly conforming authorization servers. This is
essentially, then, an anti-interoperability recommendation.

Thus, I don't believe we can leave the recommendation as is.

*Side issue probably not for the profile but for UMA generally*

As an aside, it should be noted that, even though the requesting party
should be the "same entity" referred to in both the AAT stage and later on,
the authorization server still shouldn't use the AAT to "mine" the identity
of the requesting party for trust elevation at the later stage. This is a
temptation we discovered some integrators may fall prey to, which leads to
a potential privacy violation.

I've been meaning to add a note about this to the UMA Implementer's Guide
<http://kantarainitiative.org/confluence/display/uma/UMA+Implementer%27s+Guide?src=contextnavchildmode>;
I'll leave the longer explanation about this for another time (or the UIG
itself).

*Acknowledgment of the larger UMA issue and suggestions for potential
profile fixes/additions*

The constraint where the requesting party needs a "login account" of some
sort at the authorization server used by the resource owner -- let's call
it "the resource owner's authorization server" (RO's AS), vs. "the
requesting party's desired authorization server" (RqP's AS), that is, the
authorization server the requesting party *uses for preference* when
they're in the resource owner role themselves -- is indeed a tricky one.

(In case people are wondering where the motivation for this requirement
came from, the passage quoted above describes a key one having to do with
experience: *UMA Core Sec 1.3.2:
<https://docs.kantarainitiative.org/uma/draft-uma-core-v1_0_1.html#authorization-api>
"... **The
authorization server is able to use this association to manage future
processes of authorization and claims-caching efficiently for this
client/requesting party pair across all resource servers they try to
access; however, these management processes are outside the scope of this
specification." *We shall see whether this was the right optimization
choice at this stage of UMA's life cycle... :-) )

One perhaps semi-satisfying workaround for the purposes of our profile
might be to recommend that the authorization server offer the requesting
party the opportunity to single sign-on into the RO's AS using their "RqP's
AS" login (if they have one). One could imagine an identity trust framework
among authorization servers so that they're relying parties/identity
providers to each other in a "star of trust".

*A thought about interactions between the basic profile and higher-order
profiling for trust elevation*

At ForgeRock we have recently prepared some materials that describe ways to
do identity-claims-based trust elevation given different widths of UMA
"ecosystem", once the AAT layer has been laid down. I'd be happy to share
these materials as food for thought.

Note: They may have some interactions with the basic HEART UMA profile if
we get into recommending any particular federated identity patterns at this
basic level, so let me know if you think I should add those materials to
*this* thread.

*Suggestion for handling the unfortunate Implementer's Draft timing*

I realize that what I'm talking about here is not really a non-normative
change to the wording. However, if I'm looking at the commits correctly, it
appears that this change was made as part of a flurry of edits on December
1, which is fairly late in the game for a substantive revision (I myself
was in the wilds of Norway and unfortunately not keeping up with regular
work very well!). Looking at the list traffic, I'm unclear what requests
actually led to this change.

I think it would be appropriate to hold off on the ballot, if possible,
until we discuss what to do with this text. If things are already in the
works (Debbie?), then I think we may possibly be looking at another
Implementer's Draft with some alternative (normatively changed) wording. As
explained to us previously, we can theoretically have as many of these
drafts as necessary, so we know it's possible, even if not ideal.

*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 Thu, Dec 3, 2015 at 1:38 PM, Justin Richer <jricher at mit.edu> wrote:

>
> User delegated means an end user delegates access and is involved in the
> process. Non-delegated means the client is acting on its own behalf for
> that step. This text is saying the RO needs to set up the relationship
> between the RS and the AS, but the RqP doesn’t have to be present on the
> wire to set up the relationship between the client and AS. This is to patch
> around a technical limitation in UMA 1.0 that would otherwise require the
> RqP have an account of some type at the AS that was able to generate OAuth
> tokens.
>
>
>  — Justin
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20151208/1ce27b46/attachment.html>