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

[Dick Hardt <[e-mail]>]

Curious: How are you envisioning the client communicates to the AS if it is
on the User's phone?
ᐧ

On Sun, Jul 19, 2020 at 9:13 PM Tom Jones <[e-mail]>
wrote:

> Well, that might work for you. It won’t work for me. I put the as on the
> user’s phone. The source and sink of the data can switch roles on a
> millisecond basis. I will track your progress and adopt what I can.
>
> ..Tom's phone
>
> On Jul 19, 2020, at 1:45 PM, Dick Hardt <[e-mail]> wrote:
>
> 
> Hi Tom
>
> The proposal is that Client asks for a claim from the AS, the user
> consents at the AS, and the AS directly releases the claim directly to the
> Client. No access token. No resource server.
>
> Simpler for Client and Grant Server (AS)
>
>
>
>
>
>
> On Sat, Jul 18, 2020 at 7:34 PM Tom Jones <[e-mail]>
> wrote:
>
>> absolutely, yes, tha az token can authorize any resource held by the
>> resource server.
>> The ONLY thing special about PII is the protection granted by the various
>> privacy laws.
>>
>> As an aside, I don't find much in the current discussion that gives me a
>> warm feeling about privacy.
>> The stuff in the torsten tokens is about as anti-privacy an effort as
>> exists today.
>> Identity assurance does NOT need to be enabled by sending more and yet
>> again more PII.
>> Peace ..tom
>>
>>
>> On Sat, Jul 18, 2020 at 5:58 PM Dick Hardt <[e-mail]> wrote:
>>
>>> Hey Tom
>>>
>>> While I think defining claims is out of scope of the WG, I think
>>> enabling a client to obtain claims about a user is in scope.
>>> Would you consider authorization for the release of claims to be part of
>>> the purpose of this WG?
>>>
>>> I'm concerned about the XYZ shift to subject identifiers from claims,
>>> and pushing claims to a higher layer, as it may indicate to developers that
>>> they can ONLY ask for a user identifier.
>>>
>>> When I think of a claim, I include any and all identifiers, but I also
>>> include user attributes such as under-13, over-21,
>>> student-at-an-accredited-school, resident of city/state/province/country.
>>>
>>> GNAP can enable a client to ask for only the claims it needs, preserving
>>> user privacy, and compliance with many privacy regulations.
>>>
>>> Would you agree?
>>>
>>> /Dick
>>>
>>>
>>>
>>>
>>> On Sat, Jul 18, 2020 at 9:56 AM Tom Jones <[e-mail]>
>>> wrote:
>>>
>>>> I agree with Justin's comment " what we should do, as we define GNAP as
>>>> a protocol, is focus on this one, limited slice of the identity space and
>>>> not spiral into others."
>>>> The title "Authorization" should rule the purposes of this group above
>>>> all else.
>>>>
>>>> The earlier statement that the client should know who the user is - is
>>>> just plain WRONG. The client should only know the information the user is
>>>> willing to share with the client.
>>>> It is now the law in California that the client cannot demand identity
>>>> information that is not required for a legitimate business purpose.
>>>> There are some clients that act as fiduciaries for the user
>>>> (financial and healthcare come to mind), but as a general rule the "client"
>>>> is not to be trusted by the user.
>>>> I understand most of the people on this list are paid by the client's
>>>> of the world, but you are still bound by the laws that apply to those
>>>> clients.
>>>>
>>>> Peace ..tom
>>>>
>>>>
>>>> On Mon, Jul 13, 2020 at 12:31 PM Justin Richer <[e-mail]> wrote:
>>>>
>>>>> A quick note, as my choice of language below seems to have been
>>>>> confusing. First there is a typo, where the word “it” should have been “in”
>>>>> to read:
>>>>>
>>>>> I am saying that GNAP, *in* its definition within this working group,
>>>>> should be limited to identifier claims.
>>>>>
>>>>>
>>>>> And second, there seems to be confusion around whether I’m trying to
>>>>> argue about the scope “allowed” by the charter by saying “its definition
>>>>> within this working group” here.
>>>>>
>>>>> To be clear, we as the working group are *defining* GNAP the
>>>>> protocol. It has not yet been defined, and that’s why were all here. The
>>>>> charter doesn’t define it. The input specs don’t define it. The working
>>>>> group defines it, and my stance as a contributor to this WG is that we
>>>>> should focus on a delegation protocol with some basic identifier query
>>>>> support and leave the full fledged identity protocol to different work.
>>>>>
>>>>> We’ve already got our hands full here without taking all of that on,
>>>>> especially since I do believe we need to build GNAP in such a way as to
>>>>> facilitate its extension in several known directions, including a full
>>>>> identity protocol. If we do things right here, we can see GNAP as the basis
>>>>> of a large number of things out there in the world.
>>>>>
>>>>> So my stance in what we should do, as we define GNAP as a protocol, is
>>>>> focus on this one, limited slice of the identity space and not spiral into
>>>>> others.
>>>>>
>>>>>  — Justin
>>>>>
>>>>> On Jul 13, 2020, at 2:51 PM, Justin Richer <[e-mail]> wrote:
>>>>>
>>>>> I am saying that GNAP, it its definition within this working group,
>>>>> should be limited to identifier claims. Other claims can come from other
>>>>> protocols properly layered on top of GNAP. GNAP shouldn’t stop them from
>>>>> being built, but in my opinion we shouldn’t be defining those here. See the
>>>>> discussion below on the extensibility avenues of this approach.
>>>>>
>>>>>  — Justin
>>>>>
>>>>> On Jul 13, 2020, at 2:12 PM, Dick Hardt <[e-mail]> wrote:
>>>>>
>>>>> I agree that an API to return claims is useful. I think we have agreed
>>>>> on that.
>>>>>
>>>>> Using the SubjectIdentifiers schema is another schema that would be
>>>>> useful for GNAP to support.
>>>>>
>>>>> I disagree that GNAP should be limited to identifier claims.
>>>>>
>>>>> ᐧ
>>>>>
>>>>> On Mon, Jul 13, 2020 at 7:16 AM Justin Richer <[e-mail]> wrote:
>>>>>
>>>>>> One thing I think we should learn from OIDC is that returning claims
>>>>>> from an API, and not just an assertion or direct response, is a powerful
>>>>>> and useful pattern. We have an opportunity to separate these cleanly, where
>>>>>> OIDC didn’t have the opportunity in defining the “claims” request parameter.
>>>>>>
>>>>>> As an alternative to the current XYZ and XAuth syntaxes, over the
>>>>>> weekend I’ve been playing with something that would look like this strawman
>>>>>> in the request:
>>>>>>
>>>>>>
>>>>>> {
>>>>>>    subject: {
>>>>>>       id: [ “account”, “email”, “iss-sub”],
>>>>>>       assertion: [ “odic_id_token”, “verifiable_credential”, “saml" ]
>>>>>>    }
>>>>>> }
>>>>>>
>>>>>>
>>>>>> This request says that I’d like some subset of these identifiers (as
>>>>>> plain text in the response) and some subset of signed assertions in the
>>>>>> given formats. Each one would have an associated space in the return. I’m
>>>>>> not picturing that the “id” field values would affect the contents of the
>>>>>> assertions: so I could ask for an email address identifier but get back an
>>>>>> ID token that had only the subject identifier. Maybe that’s not the right
>>>>>> model? But it’s at least simple and deterministic this way, and it’s
>>>>>> something to play with.
>>>>>>
>>>>>> Note: The “id” names are taken from
>>>>>> https://tools.ietf.org/id/draft-ietf-secevent-subject-identifiers-05.html,
>>>>>> the “assertion” names are made up as I didn’t see a source that collected
>>>>>> them. If you wanted specific bundles of claims about the user from a
>>>>>> UserInfoEndpoint, for example, you’d have something like:
>>>>>>
>>>>>> {
>>>>>>    subject: {
>>>>>>       id: [ “account”, “email”, “iss-sub”],
>>>>>>       assertion: [ “odic_id_token”, “verifiable_credential”, “saml" ]
>>>>>>    },
>>>>>>    resources: [{
>>>>>>        type: “userinfo”,
>>>>>>        datatypes: [ “openid”, “profile”, “phone”, “email” ]
>>>>>>   }]
>>>>>> }
>>>>>>
>>>>>>
>>>>>> This is an example for a specific kind of resource, and I don’t think
>>>>>> that GNAP should define the “userinfo” schema here, or the datatype values
>>>>>> therein. That should be work outside of GNAP, probably for the OIDF.
>>>>>>
>>>>>> This approach is extensible in several ways, each of them for a
>>>>>> specific reason that I think is clear:
>>>>>>
>>>>>>  - new values in the “id” field to give new identifiers
>>>>>>  - new values in the “assertion” field to give new assertion formats
>>>>>>  - new fields under the “subject” heading
>>>>>>  - new resource types besides “userinfo” (like “scim-v1” or
>>>>>> “facebook-profile” for instance)
>>>>>>  - new datatypes within the “userinfo” resource type
>>>>>>  - new top-level request parameters
>>>>>>
>>>>>> As per the other thread, if you wanted to use the OIDC query
>>>>>> language, you’d package it separately as a top-level request parameter
>>>>>> since it can include both the ID token response and the access token
>>>>>> response and we shouldn’t be encouraging mixing these things together.
>>>>>>
>>>>>>  — Justin
>>>>>>
>>>>>> On Jul 10, 2020, at 5:00 PM, Dick Hardt <[e-mail]> wrote:
>>>>>>
>>>>>> It looks to me that our different views of what is in scope for GNAP
>>>>>> are the differences below.
>>>>>>
>>>>>> Per the subject line, I'm looking at how the client acquires claims
>>>>>> about the user. You don't think that is in scope, and that a different
>>>>>> layer will solve that.
>>>>>>
>>>>>> I think we should learn from OIDC being on top of OAuth, and GNAP
>>>>>> should be able return ANY claim, not just identifier claims. There are use
>>>>>> cases that may be difficult to support if we do not have that functionality
>>>>>> in scope, such as some of the ones I list below, and it seems pretty
>>>>>> straightforward to support ANY claim if we are supporting identifiers.
>>>>>>
>>>>>> /Dick
>>>>>>
>>>>>>
>>>>>> On Fri, Jul 10, 2020 at 1:09 PM Justin Richer <[e-mail]>
>>>>>> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Jul 10, 2020, at 2:15 PM, Dick Hardt <[e-mail]>
>>>>>>> wrote:
>>>>>>>
>>>>>>>
>>>>>>> inline ...
>>>>>>>
>>>>>>> On Thu, Jul 9, 2020 at 5:44 PM Justin Richer <[e-mail]>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Yes, the core idea is to not have to parse an assertion to get back
>>>>>>>> the core authentication information, which consists of an identifier
>>>>>>>> (iss/sub pair in OIDC, but could be a number of things). Sometimes the
>>>>>>>> client is going to want the rest of the identity information, but If the
>>>>>>>> user’s logged into the client before, the client has likely cached that
>>>>>>>> info and probably won’t need it, and sending it would be a violation of
>>>>>>>> privacy principles.. The client would want the info pretty much just in
>>>>>>>> these cases:
>>>>>>>>
>>>>>>>>  1. The client has never seen the user before.
>>>>>>>>  2. The user’s information has been updated since the last time the
>>>>>>>> client saw it.
>>>>>>>>
>>>>>>>
>>>>>>> Agreed
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> Now for case (1), how would the client know if it wants to request
>>>>>>>> the user’s profile info or not, since it doesn’t know who the user is?
>>>>>>>>
>>>>>>>
>>>>>>> But the client could know who the user is. The client may have used
>>>>>>> a different AS to authenticate the user.
>>>>>>>
>>>>>>>
>>>>>>> In these cases, the client is not going to be requesting identity
>>>>>>> information from the AS to log the user in, so it’s not relevant to the use
>>>>>>> case. The client will have an opportunity to push that information to the
>>>>>>> AS.
>>>>>>>
>>>>>>> The User may have self identified to the client. The client may have
>>>>>>> a cookie saying who the user was and the user said that was them. While the
>>>>>>> latter cases are really a strong hint, they are likely right most of the
>>>>>>> time and can lead to a user experience basde on that hint
>>>>>>>
>>>>>>>
>>>>>>> In these cases, the AS might be able to guess if the client has info
>>>>>>> about the user already, but probably not. And the assumptions fall apart if
>>>>>>> it’s in fact a different user that ends up logging in, which is of course
>>>>>>> possible (the hint you gave doesn’t match the identity of the current user
>>>>>>> after the AS validates them). This possibility leads to clients always
>>>>>>> asking for everything every time and the server providing everything every
>>>>>>> time. That’s a pattern I think we should avoid in an ultimate solution —
>>>>>>> but ultimately, I don’t think that this kind of protocol decision is inside
>>>>>>> of GNAP.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> And the AS won’t know if client is going to want the profile info,
>>>>>>>> since the AS won’t know if the client has the user’s info or not. Sure, the
>>>>>>>> AS might have seen that client and that user combo previously, but it
>>>>>>>> doesn’t know if the client needs an update.
>>>>>>>>
>>>>>>>
>>>>>>> The client can share with the AS the user it knows or thinks it is
>>>>>>> dealing with, which could let the AS respond if the information was new.
>>>>>>> This could be the case for an AS that is providing claims, but not
>>>>>>> authentication, and could happen silently. The user would only interact if
>>>>>>> the user information had changed, and the client wanted the updated
>>>>>>> information.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> See above.
>>>>>>>
>>>>>>>
>>>>>>>> And for (2), the client won’t know if the user’s info has been
>>>>>>>> updated or not because it doesn’t know who the user is yet. If the AS can
>>>>>>>> provide some time of updated stamp to the client, the client can pull the
>>>>>>>> new info when it needs it.
>>>>>>>>
>>>>>>>
>>>>>>> See above.
>>>>>>>
>>>>>>>
>>>>>>> See above.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> If you ignore both of these cases and put all the user information
>>>>>>>> inline with the main request/response, you end up in a situation where the
>>>>>>>> client always requests everything and the server always provides
>>>>>>>> everything, since you can’t be sure you’re not in situation (1) or (2)
>>>>>>>> ahead of time.
>>>>>>>>
>>>>>>>
>>>>>>> See above. There are a number of other states the client could be in.
>>>>>>>
>>>>>>> For example, the client could be stateless about user information,
>>>>>>> so it knows it is ALWAYS in state 1.
>>>>>>>
>>>>>>>
>>>>>>> A stateless client would need to fetch appropriate user information
>>>>>>> every time, then. But that’s an optimization for a very specific case.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> This is really what I mean about the two-stage identity protocol.
>>>>>>>>
>>>>>>>
>>>>>>> I know what it is. Per above, GNAP lets us support a wider set of
>>>>>>> use cases. Why limit ourselves to what OIDC supported?
>>>>>>>
>>>>>>>
>>>>>>> We aren’t limiting the protocol, but instead limiting the scope of
>>>>>>> what we define internal to the GNAP protocol. There’s a lot of room for
>>>>>>> innovation on top of it.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> In the first stage, you push the bare minimum of what you need to
>>>>>>>> get the user known to the client. In the second stage, the client uses its
>>>>>>>> access token to call an API to get whatever else it needs to know about the
>>>>>>>> user.
>>>>>>>>
>>>>>>>
>>>>>>> From a privacy perspective in non-enterprise use cases, I think the
>>>>>>> user should give consent to any updated personal information to a client.
>>>>>>> In general, the client should not be able to get the latest information
>>>>>>> about a user whenever it wants.
>>>>>>>
>>>>>>>
>>>>>>> This is about the rights associated with the access token, then. And
>>>>>>> an access token doesn’t have to keep working if the AS has a policy that
>>>>>>> says it won’t. The AS/RS could easily decide that a particular access token
>>>>>>> will only return data that hasn’t been changed. Maybe it stops working
>>>>>>> after the data changes, or it just returns old data, or any number of
>>>>>>> things. This is for the AS/RS to decide and this is pretty standard
>>>>>>> interpretation of the token, nothing special here because we’re dealing
>>>>>>> with identity.
>>>>>>>
>>>>>>>  — Justin
>>>>>>>
>>>>>>>
>>>>>>> /Dick
>>>>>>> ᐧ
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>> --
>>>>> Txauth mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/txauth
>>>>>
>>>>>
>>>>> --
>>>>> Txauth mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/txauth
>>>>>
>>>>