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

[Tom Jones <[e-mail]>]

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
>>>>>>
>>>>>