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

[Tom Jones <[e-mail]>]

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