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

[Francis Pouatcha <[e-mail]>]

Before we dive into discussion on claims, we really do need some sort of
agreement on words like:

- User : I am ok if we find a replacement for this word in the current
draft.
- RO
- Agents (user Agent, RO Agent, ...)

Privacy concerns can be discussed more effectively once we have settled on
those terms.

Best Regards.
/Francis

On Mon, Jul 20, 2020 at 6:14 PM Tom Jones <[e-mail]>
wrote:

> if the user must authorize access to the resource, then what better place
> for it than their phone. I don't much worry about inconveniencing some
> gigantic corporation.
> I should be clear tho, *user agents* do not need to be on user phones, i
> was addressing my particular need.
> If the user has delegated authority to some cloud based service, then that *user
> agent *could could also host an as.
> It is interesting to speculate on whether an IdP (openId provider e.g.)
> could ever be a trusted *user agen*t. Given what I understand of the
> market today, I guess that is not possible. Markets do, however, change.
> Some on the list speculate that the client (sink of user resources) could
> be a *user agent*.  That is, at least, problematic, but conceivable.
> I, personally, would not conflate a client with a *user agent.* After
> all, the user agent has access to (at least some) user accessible resources.
> maybe you should just rename the as to be a *user agent.* Or at least
> state that the as is an endpoint of a user agent.
>
> BTW, for me a user is an identifier claiming to represent a human at a
> device. Whether they are the RO or a guardian is not of importance here. I
> know others have other definitions, sorry about that.
> Peace ..tom
>
>
> On Mon, Jul 20, 2020 at 12:30 PM Dick Hardt <[e-mail]> wrote:
>
>> 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
>>>>>>>
>>>>>> --
> Txauth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/txauth
>


-- 
Francis Pouatcha
Co-Founder and Technical Lead
adorsys GmbH & Co. KG
https://adorsys-platform.de/solutions/