Re: [Txauth] Polymorphism (Was: JSON Schema?)

[Dick Hardt <[e-mail]>]

On Wed, Jul 8, 2020 at 1:02 PM Justin Richer <[e-mail]> wrote:

> On Jul 8, 2020, at 3:16 PM, Dick Hardt <[e-mail]> wrote:
>
>
> I think representing the request as an array is simplistic, and
> complicated at the same time.
>
> On the simplistic front, as there is no clear mechanism for extending the
> request with properties that apply to all of the request.
>
>
> The elements of the array are taken as a set, to be tied to the same
> resulting access token. If one of those elements is defined, by the AS
> and/or the RS’s it’s protecting, to apply across some or all of the other
> elements, then that’s up to the AS’s policy. Much like the “openid” scope
> in OIDC, which switches on all sorts of contextual stuff in the request. So
> to handle something like this, an AS can easily declare that a given
> scope-style string or a given object property applies to different parts of
> the request. You don’t need to externalize it here.
>

I view the "openid" scope as an unfortunate design as OIDC was constrained
by building on top of OAuth. (a problem I hoped to avert by having
"identity" in scope for GNAP) The "openid" scope does not function as
scope per se, and I think it makes OIDC harder to understand as the
"openid" scope causes non-scope behavior.



>
> Do you have a concrete use case that requires that feature to be done in
> the way that you describe? I am trying to separate the driving use case
> from the proposed solutions to see what the differences are.
>

Perhaps the client wants access to be HIPPA compliant? The HIPPA compliance
signal applies to the scopes.

Adding other properties to an object is a well understood extension
mechanism. Adding an additional element to an array that does not act like
the other elements seems like a hack.



>
>
> Using JSON type polymorphism requires the AS to test each member of the
> array to determine if it is a string or an object. Only after detecting a
> RAR object does the AS know the client is making a RAR request.
>
>
> That’s correct — but the AS needs to parse the whole resources request in
> order to figure out what the client is asking for, anyway, whether it’s by
> strings or objects or whatever else might be defined by an extension. Is
> there an argument for having an AS do an early dispatch on a request before
> it’s fully parsed everything?
>

Let me clarify, the code is looking at the type of object that has been
parsed.

Determining if an item in an array is a scope or a RAR object by looking at
the type being either a string or an object seems less clear than a
property of an object explicitly declaring the type.



>
> This also limits the request to be composed only of scope strings or RAR
> objects. I don't see how other strings or objects could be used in the
> array, so there is no clear extension point in the "resources" array for
> other query mechanisms.
>
>
> That’s not the case in XYZ since we aren’t declaring that a string has to
> be an OAuth2-style scope. It can be, but ultimately it’s just a string that
> the AS can understand. And the objects are just that — objects. If the AS
> understands what the object is, it can be a RAR object or it can be
> something completely API-specific with another query language entirely.
>

But the other query language would need a type that has been reserved in
the RAR name space for there to be interop, so it effectively is a RAR
extension.

There are query languages in other domains that may not fit nicely into RAR
such as a query for medical records.

Yes, the medical records could be yet another top level property, but per
below, I think that is confusing.


> (Point, though: RAR already pretty much allows this by letting them be
> extended infinitely, a feature it inherits from XYZ)
>
> I’m proposing that we do the same thing with GNAP: it’s an array of
> strings or objects and each of those means the same thing, “something the
> client is asking for”.
>
>
> Just as RAR has a "type" property, I propose the "resources"
> ("authorizations" in XAuth) be an object, where the other properties are
> determined by the "type" property. This allows extensions to define new
> ways to query for an authorization rather than having to fit into scopes or
> RAR.
>
>
> It’s my stance that this is an unnecessary limitation at this level. The
> objects within the array should be typed, like RAR, but it doesn’t make
> sense for the overall request to be typed. Instead, there should be one
> “type" of query in the core, what XYZ calls the “resources” request. Other
> query languages should be added as extensions either to the RAR-style
> objects (by defining a type at that level) or as a separate top-level
> member.
>
> For example, let’s take the OIDC “claims” query language. My current
> thought is that this really shouldn’t be a part of the “resources” or
> “claims” part of the request, but instead as its own top-level member, like
> it is in the OIDC protocol today. The main reason for this is the nature of
> the OIDC claims language: it specifies targets for the resulting data, and
> those targets cross different ways to return things. So it doesn’t actually
> affect just resources like the UserInfo Endpoint, or the ID Token, but both
> and potentially others out there. If your system supported such an
> extension, it could theoretically forego both the built-in “claims” and
> “resources” parts of the request, and use the “oidc_claims_query” member
> (or whatever it would be called). This would let such an extension use the
> OIDC claims processing mechanism as it is today.
>
> To me, this remains much more understandable, extensible, and clean.
>

While this may be more understandable to a developer just porting an app
OIDC that only wants OIDC results, but I think it is more complicated as
soon as the developer wants other results, which is likely what prompted
the developer to use GNAP instead of ODIC.

I think it is easier to understand if all the claims are in one container,
and all the authorizations are in another container.

If a developer wants access to some resources, some claims, and an OpenID
Token, they are having to use "claims", "resources", and
"oidc_claims_query".  Now the claims and access tokens are spread across
multiple containers. There are some claims in the "claims" container, and
some "claims" in the "oidc_claims_query" container. And is the access token
response in "oidc_claims_query" the same as an access token response in
"resources"? It would seem simpler if they were, and if all the access
tokens came back in the same container.

Per Aaron's post that you have referred to, the developer can get sme bare
claims directly in the response in the "claims" object, an ID Token that
has the same or different claims, and if they want, an access token that
they can call a user_info endpoint to get the same, or different claims.

For example, an enterprise app client may want an ID Token with the email
address, bare claims for the user's name and a URI to a profile photo, and
an access token to query which groups a user belongs to.

We are still re-using the OIDC claims, but we are not mixing claims and
authorizations.

/Dick


[1] https://aaronparecki.com/2019/07/18/17/adding-identity-to-xyz
ᐧ