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

[Dick Hardt <[e-mail]>]

Yes. Which is why I referred to Aaron's post originally which calls out for
returning plain text claims.

I don't really understand what you mean by "OIDC claims query language".
The claims mean the same thing. And I was also reusing the modifiers such
as {"essential": true}. What top level functionality are you referring to?

On Thu, Jul 9, 2020 at 12:21 PM Justin Richer <[e-mail]> wrote:

> Ah, so you’re saying that the “userinfo” claims would be returned
> directly? I didn’t realize that you had intended to change how the OIDC
> claims query language functioned in your examples, and had assumed it would
> work the same was as the spec you were referencing. Your example of
> splitting it up makes that more clear. Though I would argue at that point,
> you’re creating a new query language since you’re not using the top-level
> functionality from ODIC’s definition.
>
>  — Justin
>
> On Jul 9, 2020, at 3:15 PM, Dick Hardt <[e-mail]> wrote:
>
> You are jumping to many conclusions below. Let me break down the proposal
> into some bite size chunks.
>
> The developer would like to get some plain text OIDC claims about the user:
>
>     "claims":{
>         "oidc": {
>             "userinfo" : {
>                 "name" : { "essential" : true },
>                 "photo" : { "essential" : false }
>             },
>
> The developer would like to get an OIDC ID Token:
>
>     "claims":{
>         "oidc": {
>             "id_token" : {
>                 "email"          : { "essential" : true },
>                 "email_verified" : { "essential" : true }
>             }
>     }
>
> The developer would like to get an access token to acquire OIDC claims:
>
> "authorizations": {
>         "type":"oidc",
>         "claims": ["name", "picture"]
>     }
>
> The developer would like to get an access token to access photos:
>
> "authorizations": {
>         "type":"oauth_scope",
>         "scope": "read_photos"*
>     }
>
> The developer would like to get some VC claims:
>
> "claims" {
>         "vc": {
>             "some_vc": "query_mechanism"
>         }
> }
>
> The developer would like to do all of the above at once:
>
> {
>     "authorizations": {
>         "userinfo": {
>             "type":"oidc",
>             "claims": ["name", "picture"]
>         },
>         "photos": {
>             "type":"oauth_scope",
>             "scope": "read_photos"
>         }
>     },
>     "claims":{
>         "oidc": {
>             "id_token" : {
>                 "email"          : { "essential" : true },
>                 "email_verified" : { "essential" : true }
>             },
>             "userinfo" : {
>                 "name" : { "essential" : true },
>                 "photo" : { "essential" : false }
>             }
>         },
>     "vc": {
>         "some_vc": "query_mechanism"
>         }
>     }
> }
>
> In the results, the developer gets claims back in the response claims
> object, and access tokens etc. back in the authorizations object. Just
> because an access token returns claims, it is still an access token.
>
> Yes, the developer can't get a single access token that can both acquire
> OIDC claims, and access photos (there are separate tokens for each), but I
> would argue that separating the access is a positive security property, as
> a client component accessing the user profile has a token independent of
> the client component accessing photos. And at the AS, there is no
> requirement for the userinfo endpoint to take the same token as the photo
> endpoint.
>
> Somewhat of a tangent, I'm thinking that
>
>     "claims":{
>         "oidc": {
>             "id_token" : {},
>             "userinfo" : {}
>         },
>
> is a little verbose, and:
>
>     "claims":{
>         "oidc_token": {},
>         "oidc_info": {}
>     },
>
> works better and makes it easier to distinguish support for ID tokens vs
> plain claims.
>
> wrt. my position on reusing OIDC -- it has not changed. I have viewed the
> OIDC claims as the "query language". No need to reinvent that. We are
> creating a new protocol, so no need to use the OAuth or OIDC protocols.
>
> * OAuth scopes could be a space separates string to be consistent with
> OAuth 2, or an array of strings so that it is more JSON like. I have no
> strong opinion.
>
> scope.split(' ').forEach()
>
> is not that much more complex than
>
> scope.forEach()
>
>
>
> On Thu, Jul 9, 2020 at 8:39 AM Justin Richer <[e-mail]> wrote:
>
>> But this approach doesn’t keep things in their respective containers —
>> you’ve explicitly got “claims” underneath the “authorizations” header, and
>> you’ve got items that come back as rights associated with the access token
>> (which should be “authorizations”) in the “userinfo” section under the
>> “claims” header. And as far as I can tell, these two sections are redundant
>> to each other. Everything is everywhere.
>>
>> Additionally, this approach and syntax makes it difficult to combine
>> different kinds of requests into one. One of OpenID Connect’s biggest
>> draws, as I’m sure you recall, is that it could be combined with a request
>> for non-OIDC resources. This was the real innovation that Twitter and
>> Facebook’s identity APIs brought, access to more than just authentication,
>> and what Google had tried to replicate with the awkward OpenID 2 + OAuth 1
>> hybrid system. Taking a step back from the existing solutions of OpenID 2
>> and OAuth 1 let us, as the community, see the value in the pattern that
>> became OIDC on top of OAuth 2.
>>
>> Sure, you could say that the “oidc” type also can allow a “scopes”
>> parameter, but what about a RAR style object, then? And what about when
>> someone comes up with some new way to request access rights, or a VC-based
>> query language? Does every “type” need to now know about every other “type”
>> in order for an AS to be able to figure out how they go together? This
>> seems like the protocol definition limiting what combinations the AS can
>> handle, or what an RS might want to use.
>>
>> My stance is that GNAP should have a way to query for rights in the
>> access token (“authorizations” in xauth parlance) and identifiers for the
>> user (“claims” in xauth parlance), and anything else should be an extension
>> with potentially different models. The AS would process the
>> “authorizations” equivalent (for the access token) alongside any other
>> incoming query and then make a policy decision based on that.
>>
>> I find it interesting that you are now saying we don’t need to use the
>> OIDC request format when previously you’ve made it clear that you were in
>> favor of pointing at external query languages, including their syntax. I’m
>> glad to see that you’re now looking at things in a more flexible way, but I
>> think it’s important that we be careful and conscientious about how we
>> reference any external query languages in GNAP.
>>
>>  — Justin
>>
>> On Jul 8, 2020, at 6:55 PM, Dick Hardt <[e-mail]> wrote:
>>
>> Hey Justin,
>>
>> Just because we are using OIDC claims, does not mean we need to mimic the
>> OIDC request and response.
>> I was envisioning a grant request could look as the following (using
>> XAuth syntax):
>>
>> {
>>     "authorizations": {
>>         "type":"oidc",
>>         "claims": ["name", "picture"]
>>     },
>>     "claims":{
>>         "oidc": {
>>             "id_token" : {
>>                 "email"          : { "essential" : true },
>>                 "email_verified" : { "essential" : true }
>>             },
>>             "userinfo" : {
>>                 "name"           : { "essential" : true },
>>                 "picture"        : null
>>             }
>>         }
>>     }
>> }
>>
>> Of course a developer could choose to only ask for a subset of this.
>>
>> Note the new authorization type of "oidc", that takes "claims" rather
>> than "scope".
>>
>> This keeps all the authorizations and claims in their respective request
>> and response containers.
>>
>> We had a thread months ago on the OIDC two stage model, and I still fail
>> to see why forcing that has any advantage.
>>
>> /Dick
>>
>>
>> On Wed, Jul 8, 2020 at 3:25 PM Justin Richer <[e-mail]> wrote:
>>
>>> I’m glad that we can agree that there are a number of things in legacy
>>> protocols that are unfortunate side effects of the circumstances in which
>>> they were built. Space-separated scope strings, for instance, would fall in
>>> that category, as I’ve previously explained.
>>>
>>> A key point in the below: the OIDC “claims” request already mixes user
>>> claims (returned in an API) and authorization (to fetch user claims from an
>>> API), so that ship has sailed if you’re using it. It doesn’t make sense to
>>> have it under a “claims” or “authorizations” request, since it’s a query
>>> language that affects both. Maybe you’d call this another “unfortunate
>>> design”, but the context was about re-using an externally-defined query
>>> language that was not made for GNAP.
>>>
>>> My scenario was for someone who is already using “claims” and wants to
>>> keep using it. (The vast majority of OIDC implementations, in my
>>> experience, don’t use that feature, and it’s not even required to be
>>> implemented by the AS, but again we’re talking about using this feature as
>>> an example of an external query language — and there are others out there.)
>>> In GNAP, you should return claims directly in the response, and request
>>> specific elements from the APIs protected by the access token. These are
>>> separate things, and by design both XAuth and XYZ have put them into
>>> separate containers in the request. This is a good design, and so putting
>>> something that conflates these two aspects into one or the other of the
>>> containers is not a particularly good option, in my opinion.
>>>
>>> Additionally, though this is a bit of an aside and getting into the
>>> specifics of identity, the “claims” parameter of ODIC is a query language
>>> bound to the full user profile. It is my stated position that the items
>>> coming back from the AS should only be identifiers, and not full profile
>>> information. The reasoning is pretty simple: the client doesn’t know what
>>> profile information it needs until it knows who the user is, so putting
>>> that into a protected API like the UserInfo Endpoint makes much more sense
>>> than putting it into the immediate response, where it is not needed,
>>> because the client already knows it. The AS doesn’t know what the client
>>> needs to know, either, so it can’t determine what to fulfill. OIDC’s
>>> two-stage model makes sense, and GNAP should really only focus on enabling
>>> this.
>>>
>>>  — Justin
>>>
>>> On Jul 8, 2020, at 6:10 PM, Dick Hardt <[e-mail]> wrote:
>>>
>>>
>>>
>>> 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
>>> ᐧ
>>>
>>>
>>> ᐧ
>>
>>
>> ᐧ
>
>
> ᐧ