Short term and long term RS user accounts

[Denisthemalice]

This topic has mentioned during the last interim WG meeting and it has been suggested to continue to discuss the topic on the "list". This is why I open a new issue.

Short term and long term RS user accounts are foundations to be able to under how an access token can be bound to a "buid" field (Binding User IDentifier)" contained in an access token.

Let us consider two current use cases: the purchase of a train ticket on a web site that has never been accessed before by a customer. The customer is usually offered two options:

• to perform its transaction with the opening of a user account, or
• to perform its transaction without the opening of a user account, or

In the first case, the customer is invited to choose a password and an identifier (which is usually an email address). At the end of the purchase, a long term RS user account will be created and will be reusable once the transaction has been completed. An historic of the purchases of the customer can be maintained by the RS (e.g. for asking more rapidly a similar train ticket at a later date).

In the second case, the customer is NOT invited to choose a password and an identifier. During the transaction, a short term RS user account will be used but it will not be reusable once the transaction has been completed.

In both cases, the customer MUST provide his family name and his first name(s) since these two information will be printed on or associated with the train ticket (e.g. included in the QR code of the train ticket).

Let us also consider the case where a rebate can be obtained if the customer is older than 60. However, for privacy reasons, the date of birth will not be provided.

Let us now transpose these two use cases in the context of short term and long term RS user accounts.

1) The case of a long term RS user account

The customer requests to an AS (trusted by the RS), an access token that contains both his family name and his first name as well as an indication that he is over 60. The customer provides to the AS an identifier of the target RS (e.g. a url). The customer also indicates to the AS that he is willing to get such an access token in the context of a long term RS user account.

The AS authenticates the customer (the AS does not need to authenticate the client instance) and generates a unique "buid" for this customer associated with the identifier of the target RS. This "buid" is memorized in a user account maintained by the AS. When the AS returns the access token to the user (i.e. to the client) a tuple "buid" / AS identifier (iss) is included into the access token.

The RS is then able to create a long term user account associated with the tuple : buid / AS identifier (iss).

Now let us suppose that the client of this customer (Bob) forwards this access token to Alice. If Alice accepts to use it, she will get a train ticket for Bob, but not for herself.

If Alice, who is under 60, asks for a train ticket for herself, she will not get an access token that indicates that she is over 60 and hence will not get any rebate for this train ticket.

Let us now suppose that the initial access token does not contain any age information and that the age information is only requested by the RS later on.

The access token delivered to Bob that contains the information that Bob is over 60 will contain a tuple buid/AS Identifier (iss) that is specific to Bob. If Bob transmits it to Alice and then Alice presents it to the RS, the RS will refuse this access token because it does not contain the tuple buid/AS Identifier (iss) that is specific to Alice.

This allows to support a proof of possession of an access token without the need to use any client instance key, nor any ephemeral key pair.

2) The case of a short term RS user account

If short term user accounts are being used and if access tokens with the same kind of content are being used, there is no difference in terms of proof of possession of an access token with the previous case. The key point of the previous use case is that the access token contains an identifier of the customer since his family name and first name are included into the access token.

Let us now consider a different use case where short term RS user accounts are being used but where the issued access tokens do not allow to identify the customer, for example, the access token states that the legitimate holder of the access token is over 60 and is a resident of the California state. The customer also indicates to the AS that he is willing to get such an access token in the context of a short term RS user account.

If such an access token is obtained by Bob, Bob would be able to transmit it to Alice and Alice would be able to successfully use it at the identified RS. In this context, Alice will be impersonating Bob.

Does this mean that the use of short term RS user accounts is not interesting at all ? Not really.

3) Let us now consider another different use case:

• Bob is over 60 and is a resident of the Minnesota state
• Alice is under 60 and is a resident of the California state

They want to collude together in order to demonstrate to a RS that the end user is over 60 and is a resident of the California state.

Bob asks for an access token that only contains an attribute stating that he is over 60. Alice asks for an access token that only contains an attribute stating that she is a resident of the California state.

If these access tokens are presented successively to a RS, they will be associated with two different short term RS user account and neither Bob nor Alice will be able to take advantage of the collusion.

In the context of short term RS user accounts, the use of the "buid" field prevents the addition of attributes obtained by two different end-users.

RS administrators should be vigilant about which kind of operations will be associated with short terms or long term RS user accounts.

A key feature of this mechanism is the use of a "buid" field in the access token, the value of which is not under the control of the end-user, nor of the client, but only under the control of the AS.

[jricher]

Users do not authenticate to or interact with the RS in the GNAP model. As such, the rest of this text is not relevant to the core protocol.

[Denisthemalice]

The GNAP model is still under construction. So, this is your assumption, but not mine.

The trust model in draft -07 is still missing to indicate how users can authenticate since access tokens contain attributes and /or rights associated with end users (i.e. not associated with client instances). Thus there is currently a missing link in the current description of draft-07.

This topic directly relates to the topic of access token binding which has been attempted to be solved during several years in the OAuth WG without a good solution since all these solutions are vulnerable to client collusion attacks.

Another attempt to perform a new kind of access token binding feature has been presented by yourself during the last OAuth WG meeting. Although the presented draft-00 does not contain any Security considerations section, the new proposed method does not seem to be able to counter collusion attacks between clients.

Some years ago, on the OAuth mailing list someone said that it was impossible to counter client collusion attacks. This was true in the context of OAuth (even when security modules are being used to protect client instance private keys).

At this time, outside the context of OAuth, a solution is being proposed.

At this time, it is no more possible to change the OAuth model, but it is still possible to adopt a GNAP model that is not based on the same grounds like OAuth.

The OAuth model is using keys for client instances. In order to find a secure solution for countering collusion attacks between users, this model is not adequate. A new paradigm is needed where client instance keys are no more used.

The key question is thus following:

Do we want to promote a model that is able to counter client collusion attacks (like the one I am proposing) or a model which, by design, is unable to counter client collusion attacks ?

Another point should be considered: GNAP should be targeted to be world-wide usable, including in Europe and the EU.

As of December 31 st, 2020, the European Union (EU) is requiring that consumer electronic payments over € 50 ($ 60) require MFA (Multi-factor authentication). This requirement is defined in Article 97 as part of the Payments Services Directive (PSD2) that took effect in January 2018.

https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32015L2366&from=EN

The model I am proposing allows to be compliant with the PSD2 Directive, since, by design, the protocol mandates the user to authenticate to the AS before being able to request an access token. Such a feature does not exist in draft -07.

[jricher]

No, GNAP has a model. You are assuming that you can supplant that model with your own, which is quite different (as has been discussed many times). Since GNAP does not mandate any specific authentication technology to be enforced by the AS, GNAP is able to comply with many different jurisdictions and requirements, including the EU's.

Your proposal above does not solve the "user collusion" attack that you describe, as you have yet to answer how the RS would possibly know that it's "Alice" presenting "Bob"'s access token. Having a subject identifier within the access token alone, which you are proposing, does not stop that token from being shared by different subjects. And furthermore, your model does not account for any of the many situations in which there is no user -- no person involved in the transaction.

[Denisthemalice]

1) @jricher. You wrote:

Since GNAP does not mandate any specific authentication technology to be enforced by the AS, GNAP is able to comply with many different jurisdictions and requirements, including the EU's.

Draft -07 does not mandate user authentication at all. If one were used, it would not be part of the core protocol. If a user authentication were used, the reason why it should / shall (?) be used it is not explained in draft -07.

On the contrary, in my model, user authentication is mandatory and is part of the core protocol. This makes a big difference.

2) @jricher. You wrote:

(...) you have yet to answer how the RS would possibly know that it's "Alice" presenting "Bob"'s access token. Having a subject identifier within the access token alone, which you are proposing, does not stop that token from being shared by different subjects.

Please read again the explanations that have been given about long term RS user accounts.

When the RS receives Bob's first access token, it contains the family name and the first name of Bob. At this point of time, the RS is able to know that the buid that is included into the access token corresponds to Bob. If another access token is received from the same AS and if it contains the guid associated with Bob's familiy name and first name, it cannot belong to a guid associated with the family name and first name of Alice (and vice versa). This stops that token from being shared by different subjects when long term RS user accounts are being used.

3) @jricher. You wrote:

And furthermore, your model does not account for any of the many situations in which there is no user -- no person involved in the transaction.

You have already mentioned this argument during the last interim WG meeting. Unfortunately, this argument is in contradiction with one of the definitions of draft -07 which is on page 7 and defines a client in the following way:

Client : application operated by an end-user that consumes resources from one or several RSs, possibly requiring access privileges from one or several ASs.

A client which would not be operated by an end-user cannot exist with such a definition. Hence this definition does not allow to say that there can exist situations in which there is no user -- no person involved in the transaction.

[jricher]

1) user authentication happens at the AS, details are defined as out of scope in section 4

2) I have read and understood what you're proposing. You have not answered the question: when Alice submits Bob's token, how does the RS know it's Alice submitting the token? You've described a way for the RS to know it's Bob's token, something already well established by, for example, the "sub" claim in JWT. But you claim that the RS will reject Alice submitting that token without explaining the mechanism by which the RS would be able to determine this. Please, go into detail, show us with HTTP messages how it would all work.

3) looks like that definition does need a clean up then, thanks! We'll fix that to align with the rest of the specification in which the end user may not be present.

[fimbault]

Yes, definition will be updated (I'll do that): "by or on behalf of an end-user"

[Denisthemalice]

@jricher. You wrote:

user authentication happens at the AS, details are defined as out of scope in section 4

I looked for the wording "user authentication". It does not exist within the whole document (unless the terms is broken on two lines).

I also looked for the wording " out of scope". This wording is used many times, but none of them refers to "user authentication".

Section 4 (page 59 ) is about "Determining Authorization and Consent"; hence, it is not the natural place to talk about "user authentication".

Would you please quote the exact sentence you refer to and indicate on which page it is ?

@jricher : You wrote:

You have not answered the question: when Alice submits Bob's token, how does the RS know it's Alice submitting the token? You've described a way for the RS to know it's Bob's token, something already well established by, for example, the "sub" claim in JWT. But you claim that the RS will reject Alice submitting that token without explaining the mechanism by which the RS would be able to determine this. Please, go into detail, show us with HTTP messages how it would all work.

When Alice submits Bob's token, the RS does not know who is submitting the token, but it knows it is a token that belongs to Bob because it contains the "guid" assigned to Bob by the issuing AS.

The key point is the following: let us suppose that both Bob and Alice have opened a long term RS user account on a given RS. If Bob transmits one on his access tokens to Alice, Alice will not be able to take advantage of it for her long term RS user account.

On her long term RS user account, for being accepted by the RS, the access token MUST contain the guid of Alice as assigned by the issuing AS. When she presents an access token that was given to her by Bob, it contains Bob's uid (and not her guid) and hence it will be rejected by the RS.

@jricher : You wrote:

looks like that definition does need a clean up then, thanks! We'll fix that to align with the rest of the specification in which the end user may not be present.

I would not consider such a change as an editorial change. This topic would be buried in the 322 nd issue that few of the WG members will ever read. For the time being, please open a new issue if you want to make such a change in the current definition and provide a rational for it, so that we can discuss it. We will need to bring it to the attention of the mailing list once we will have been able to have a few exchanges about it.

@fimbault. Please defer any change to the current definition until we have sufficiently discussed this topic.

[jricher]

User authentication is discussed all throughout section 4, which is exactly where authentication should take place. Amonth other parts is the list of things the AS can do:

authenticate the RO, through a local account or some other means such as federated login

Claiming that it doesn't exist because you searched for one phrase and couldn't find it is disingenuous misdirection, and is not engaging in good faith. Does the text say exactly what you want it to? No. Does it address user authentication in the right place? Yes.

On her long term RS user account, for being accepted by the RS, the access token MUST contain the guid of Alice as assigned by the issuing AS. When she presents an access token that was given to her by Bob, it contains Bob's uid (and not her guid) and hence it will be rejected by the RS.

It will not be rejected by the RS. It will be accepted as Bob's token, even though it was presented by Alice. That's the point I'm trying to make here, unless you can tell me how the RS knows to reject the token.

[Denisthemalice]

@jricher. I reiterate my question:

Would you please quote the exact sentence you refer to and indicate on which page it is ?

Unless you can provide one or more sentences extracted from draft-07 that refer to the end-user, as a separate entity from the RO, you argumentation is invalid.

You wrote:

It will not be rejected by the RS. It will be accepted as Bob's token, even though it was presented by Alice. That's the point I'm trying to make here, unless you can tell me how the RS knows to reject the token.

I fear that you read my explanations two fast: I am in the context of long term TS user accounts, a concept that does not currently exist in draft -07.

If Alice presents to a RS an access token that belongs to Bob, she will be able to perform some operation(s) on Bob's long term TS user account, but not her own RS user account. Thus, she cannot take advantage of the content of Bob's access token on her own long term RS user account.

This mechanism does not prevent against impersonation of an access token by another user on a RS (on the same user account).

However, at this point of time, let us consider the behavior of a wise and educated end-user. Will such end-user be really willing to transfer one of his access tokens to another user, if he is informed that that other end user will be able to impersonate him for some actions on his long term RS user account ?

What about if this access token would allow to transfer money between banks accounts ?

[agropper]

If an RS wanted to prevent impersonation through collusion, the RS could attach a biometric to the resource. This could be done directly through facial recognition or indirectly by using a driver's license or passport number.

Another long-term alternative to biometrics is reputation.

Is the goal for this use-case to design a protocol that coercively binds a biometric or a reputation to a resource?

• Adrian

On Mon, Oct 11, 2021 at 10:35 AM Denisthemalice @.***> wrote:

@.** https://github.com/jricher. I reiterate my question:

Would you please quote the exact sentence you refer to and indicate on which page it is ?

Unless you can provide one or more sentences extracted from draft-07 that refer to the end-user, as a separate entity from the RO, you argumentation is invalid.

You wrote:

It will not be rejected by the RS. It will be accepted as Bob's token, even though it was presented by Alice. That's the point I'm trying to make here, unless you can tell me how the RS knows to reject the token.

I fear that read my explanations two fast: I am in the context of long term TS user accounts, a concept that does not currently exist in draft -07.

If Alice presents to a RS an access token that belongs to Bob, she will be able to perform some operation(s) on Bob's long term TS user account, but not her own RS user account. Thus, she cannot take advantage of the content of Bob's access token on her own long term RS user account.

This mechanism does not prevent against impersonation of an access token by another user on a RS (on the same user account).

However, at this point of time, let us consider the behavior of a wise and educated end-user. Will such end-user be really willing to transfer one of his access tokens to another user, if he is informed that other user user will be able to impersonate him for some actions on his long term RS user account ?

What about if this access token would allow to transfer money between banks accounts ?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/322#issuecomment-940088225, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABB4YPNIT6EYLIYHCMNCQTUGLYZHANCNFSM5FVLG7GA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[fimbault]

Yes the liveface detection or similar (ex audio captcha) are becoming more widespread (we even have a spec called PVID in France for that). It poses quite a few challenges in terms of accessibility, but covers advanced eIDAS requirements. I don't think it fits well into an authZ framework, we shouldn't have to deal with that directly (which is why it's explicitly out of scope)

[jricher]

The document is absolutely full of references to this difference including diagrams and text.

The whole account issue discussed here between Alice and Bob is nothing more than a subject identifier associated with the access token, which is not only a long established practice it is also a topic suited for the RS draft.

This issue adds nothing to the ongoing conversation.

[jricher]

@agropper @fimbault the question of biometrics is interesting but it also assumes that these can be presented alongside the access token at the RS. This doesn't seem like the kind of thing that GNAP should solve, but instead allow another protocol to be layered on top.

[aaronpk]

This mechanism does not prevent against impersonation of an access token by another user on a RS

I'm glad you agree that there is nothing in the mechanism you described that prevents access token reuse/sharing by other users or clients.

This allows to support a proof of possession of an access token without the need to use any client instance key, nor any ephemeral key pair.

This statement is false. Client instance keys are how we gain the proof of possession property.

A key feature of this mechanism is the use of a "buid" field in the access token

This is also known as the "subject identifier" and is already described in the core spec, as well as described in OpenID Connect and the JWT Access Token draft in OAuth 2.0.

[fimbault]

@jricher I agree

[Denisthemalice]

@aaronpk: You wrote:

I'm glad you agree that there is nothing in the mechanism you described that prevents access token reuse/sharing by other users or clients.

This is not what I said. What you describe is different from user impersonation. The mechanism I have described "prevents access token reuse/sharing by other users or clients" on a long term user account that is NOT the one for which the access token is intended for.

Basically if an access token can be intercepted or is voluntarily forwarded by an end user or a client to another client, it can only be used at the intended long term RS user account which is indicated by the buid/iss pair. The mechanism described in draft -07 does not have this property.

@aaronpk :

This allows to support a proof of possession of an access token without the need to use any client instance key,
nor any ephemeral key pair.

This statement is false. Client instance keys are how we gain the proof of possession property.

This statement is true. Then, you say that client instance keys is how you gain the proof of possession property. This is true.

Since the architecture described in draft -07 does not prevent a user to communicate a client instance key to another client, an access token can be reused by any other client on the same RS for its own advantage. The mechanism I am proposing does not have this limitation: the access token can only be used for the benefits of the original access token holder.

@aaronpk :

A key feature of this mechanism is the use of a "buid" field in the access token

This is also known as the "subject identifier" and is already described in the core spec, as well as described in OpenID Connect and the JWT Access Token draft in OAuth 2.0.

This is similar but there is a huge difference. The JWT Access Token draft in OAuth 2.0. Draft -13 states:

This profile mandates the presence of the "sub" claim in every JWT access token, making it possible for resource servers to rely on that information for correlating incoming requests with data stored locally for the authenticated principal.

The text leaves open how this field should be verified or checked by a RS. None of the examples that follow corresponds to the use case I am describing. In the mechanism I am proposing, the way to check the buid field is fully described and is mandatory.

In addition, the text leaves open how this field should be populated by the AS. In the mechanism I am proposing, the way to create and populate the buid field is fully described and is mandatory.

There is a third difference: the buid field is a structured field that contains a type and a value. The checks to be done by the RS are first on that type and then on that value.

A key point of this mechanism is that a client can only choose the type the buid field, but not its value.

@jricher: I reiterate once again my question:

**_Would you please quote the exact sentence you refer to and indicate on which page it is ?_**

Unless you can provide one or more sentences extracted from draft-07 that refer to the end-user, as a separate entity from the RO, you argumentation is invalid.

[aaronpk]

Unless you can provide one or more sentences extracted from draft-07 that refer to the end-user, as a separate entity from the RO, you argumentation is invalid.

From section 1.2 "Roles"

End-user natural person that operates a client instance. Note: that natural person may or may not be the same entity as the RO.

[agropper]

To be clear, I agree with Justin that end-user authentication at the RS should be out of scope but can be mentioned in the RS document for guidance.

On Mon, Oct 11, 2021 at 4:56 PM Aaron Parecki @.***> wrote:

Unless you can provide one or more sentences extracted from draft-07 that refer to the end-user, as a separate entity from the RO, you argumentation is invalid.

From section 1.2 "Roles" https://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-07.html#name-roles

End-user natural person that operates a client instance. Note: that natural person may or may not be the same entity as the RO.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/322#issuecomment-940434170, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABB4YICMMFDHKLBDETSLP3UGNFQBANCNFSM5FVLG7GA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[fimbault]

@Denisthemalice what you propose seems very convoluted (to me) and protects against a threat operated by honest users (someone that would be cherry picking which accounts he holds private or not, supposing in good faith that sharing short term credentials is fine / especially if we'd make the design assumption that it's a legitimate need) which seems a weird case to focus on. There's still nothing in what you described that prevents sharing your long term buid, so there's no fundamental difference in the protection it supposedly provides

What Adrian described seems a more realistic use case, but again not something that's directly part of GNAP

[Denisthemalice]

@aaronpk . Your reply to the question addressed to @jricher is inadequate since it does not correspond to the original arguments which were:

Draft -07 does not mandate user authentication at all. If one were used, it would not be part of the core protocol. If a user authentication were used, the reason why it should / shall (?) be used it is not explained in draft-07.

Those arguments stay valid: user authentication at the AS is not addressed in draft-07. Draft-07 is unable to comply with the EU legislation.

@agropper : You are confusing user authentication at the RS with user authentication at the AS. We were not discussing user authentication at the RS.

@fimbault. You wrote:

There's still nothing in what you described that prevents sharing your long term buid, so there's no fundamental difference in the protection it supposedly provides.

Let me try to explain the fundamental differences between the mechanism A which is using a "guid" field in the access token and the mechanism B which is using access tokens bound to a key to demonstrate the ownership of the access token .

First of all, the mechanisms A is mandating the use of a single method (which easily allows to perform interoperability tests), while the mechanism B is allowing the use of four methods and even more of them:

The type of binding used is indicated by the proof parameter of the key object in Section 7.1.
Values defined by this specification are as follows:

• httpsig HTTP Signing signature header
• mtls Mutual TLS certificate verification
• jwsd A detached JWS signature header
• jws Attached JWS payload

The use of four or even more methods does not really allow for interoperability. This is an argument to consider draft-07 more as a framework than as an interoperable protocol specification.

The key point (already mentioned) is that in the mechanism A the legitimate owner of the access token is unable to chose the value of the "buid" field (and can only choose its type). In the spectrum of mechanisms B (and correct me if I am wrong), the key is chosen by the client and either the client can voluntarily give the private key away or, if it is unable to give the private key away, can perform all the computations that the other client needs.

Draft-07 does not mandate the presence of a "sub" claim or the like in an access token. Hence, an access token that would contain a write method to an object will be transferrable to any other client that has accepted to collaborate with the legitimate client.

This is different in the case of the mechanism A, where the presence of a "buid" claim is mandated in every access token.

Let us use an example, to illustrate the benefits of the mechanism A over the spectrum of mechanisms B.

Bob got an access token that contains an attribute stating that he is over 60. He forwards it to Alice. She will only be able to make use of it on Bob's RS user account and not on her own RS user account. She will not get a rebate for her train ticket.

If the mechanism B were used instead, she would get a rebate for her train ticket. This would be a severe security threat that would be likely to deter RS administrators to use any one of the mechanisms B.

[fimbault]

I'll read more thoroughly but as far as I'm concerned I would only keep 2 methods, httpsig and mtls. The main reason is to not put any dependance on JOSE (which people may or may not like)

[jricher]

@Denisthemalice The token structure that you describe, where users have two different resources but accept tokens with just attributes, is not something that I've seen in the wild. Instead it is extraordinarily common (and mundane) to associate an access token with the approving party -- as a delegation protocol, this is at the core of most GNAP use cases. Furthermore, as discussed above, mandating a subject identifier of any type does not solve the underlying "collusion" problem you discuss of Alice sharing her token with Bob. I'm glad that you agree that associating the access token with the client instance's key solves a different problem -- it's an important and orthogonal issue, and you can't swap one for the other, as you illustrate.

So with that in mind, it's clear that this proposal boils down to subject identification for the rights of the access token, something which is particularly important when the token or the item being accessed represents a particular user. This is of course not universal, but the RS draft (which is where we deal with what the access token represents in detail) will have security considerations that talk about this. While it's always been the plan of the editors to address this in the security considerations for that document, because it's well understood and not novel, I've filed an issue to explicitly collect these security consideration items: https://github.com/ietf-wg-gnap/gnap-resource-servers/issues/45

[Denisthemalice]

@jricher. You said:

The token structure that you describe, where users have two different resources but accept tokens with just attributes, is not something that I've seen in the wild.

FYI, it is common in the EU since it is the foundation of the current eIDAS regulation of 23 July 2014, where the following end-user attributes are mandatory:

(a) current family name(s); (b) current first name(s); (c) date of birth; (d) a unique identifier constructed by the sending Member State in accordance with the technical specifications
for the purposes of cross-border identification and which is as persistent as possible in time.

This information is in the annex of COMMISSION IMPLEMENTING REGULATION (EU) 2015/1501 of 8 September 2015 on the interoperability framework pursuant to Article 12(8) of Regulation (EU) No 910/2014 of the European Parliament and of the Council on electronic identification and trust services for electronic transactions in the internal market. See: https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32015R1501&from=EN

Note: Mandating the presence of these four attributes is far from being privacy friendly, but it is the way it is specified.

You continue with:

Furthermore, as discussed above, mandating a subject identifier of any type does not solve the underlying "collusion" problem you discuss of Alice sharing her token with Bob. I'm glad that you agree that associating the access token with the client instance's key solves a different problem -- it's an important and orthogonal issue, and you can't swap one for the other, as you illustrate.

I don't believe that I have agreed that associating the access token with the client instance's key solves a different problem which would be an orthogonal use. I believe that associating the access token with the client instance's key does not solve the access token proof of possession problem at all. Furthermore, such technique would not be "privacy friendly", since it would allow the RSs to link any access token transmitted from that client instance.

I am proposing the mechanism A as a replacement of all the variants of the mechanisms B and I am replacing the end-user (including end-user authentication at the AS) at the center of the architecture model.

In my previous post, I gave the example of an attribute stating that the access token holder is over 60, but it would work just the same if we were speaking of an access method on a given object of a RS. So the mechanism it is not specific to ABAC (Attribute Based Access Control) but also valid for CBAC (Capability Based Access Control).

I don't believe, as you said, that the method is "well understood and not novel", because the foundation of it is the use of short term and long terms RS user accounts, which are terms that I have never seen in the OAuth documents, nor in the GNAP documents.

It is not possible to only deal with this issue in the gnap-resource-server document, since the end-user should be able to make a choice between using either short term or long term RS user accounts when talking to the AS and the description should also be in the core document.

[aaronpk]

I believe that associating the access token with the client instance's key does not solve the access token proof of possession problem at all.

That is in fact exactly what a client instance key does. I suggest reading up on existing material about this concept before continuing this discussion. This is not a concept unique to GNAP, it has been widely explored and adopted in OAuth as well. If you don't understand this then I am not sure it's worth anyone's time to continue this discussion.

[jricher]

the end-user should be able to make a choice between using either short term or long term RS user accounts when talking to the AS

This is part of any interaction the user may have with the AS, which is AS-specific and out of scope for both GNAP core and GNAP-RS.

[jricher]

FYI, it is common in the EU since it is the foundation of the current eIDAS regulation of 23 July 2014, where the following end-user attributes are mandatory:

These regulations are for user authentication schemes, such as national ID cards. Access tokens are not the same kind of thing. Access tokens represent delegated access to something. They are not an identity mechanism. I recommend you start reading on the topic here: https://oauth.net/articles/authentication/

[Denisthemalice]

@aaronpk :

I believe that associating the access token with the client instance's key does not solve the access token 
proof of possession problem at all.

That is in fact exactly what a client instance key does

I have two questions:

• Would you please explain me how such a protection remains effective if the client or the end-user gives away the client instance private key to another client or end-user ?

• If the client or the end-user is unable to give away the client instance private key to another client (e.g. because it is placed into a security module or the like), would you please explain me how such a protection remains effective if the first client performs all the cryptographic computations that the other client needs ?

@jricher :

the end-user should be able to make a choice between using either short term or long term RS user accounts 
when talking to the AS.

This is part of any interaction the user may have with the AS, which is AS-specific and out of scope for both GNAP core and GNAP-RS.

With this response, you are considering that GNAP is a framework that can support any else not specified in the core protocol, whereas in my approach I am considering that the protocol SHALL support an interaction between the AS and the end-user that allows the end-user to indicate to the AS which type of "guid" (among four choices), he wants to use. This makes an important difference.

You said:

Access tokens represent delegated access to something. They are not an identity mechanism. I recommend you start reading on the topic here: https://oauth.net/articles/authentication/

Thank you for your recommendation. I read this article that was written by yourself, in the context of OAuth.

You wrote "Access tokens represent delegated access to something". Please refer to the definition given in draft-07 which states something rather different:

Access Token : a data artifact representing a set of rights and/or attributes.

This means that an access token may only contain attributes (and hence no right).

This definition clearly indicates that both CBAC (capabilities) and ABAC (attributes) can be supported and even a mixture of both of them.

The WG charter states:

This protocol enables an authorizing party to delegate access to client software to use a Resource Server (RS) with this token. It will expand upon the uses cases currently supported by OAuth 2.0 and OpenID Connect (itself an extension of OAuth 2.0).

IMO, "expanding upon the uses cases currently supported by OAuth 2.0 and OpenID Connect" means to be support to support CABC (capabilities) and/or ABAC (attributes).

https://auth0.com/docs/get-started/authentication-and-authorization indicates what authorization is :

authorization verifies whether access is allowed through policies and rules.

These "policies and rules" are not necessarily capability based.

[fimbault]

• "Would you please explain me how such a protection remains effective if the client or the end-user gives away the client instance private key to another client or end-user ?" A client instance key is not expected to be shared. It might be a threat (mitigated through appropriate security measures) but it's not standard behaviour.

• "Would you please explain me how such a protection remains effective if the first client performs all the cryptographic computations that the other client needs ?" I don't understand the use case here. Each client is independent, there's no context sharing. A client needs to manage its own keys.

• "whereas in my approach I am considering that the protocol SHALL support an interaction between the AS and the end-user that allows the end-user to indicate to the AS which type of "guid" (among four choices), he wants to use. " Indeed we don't consider that possibility.

• "Access Token : a data artifact representing a set of rights and/or attributes" We cover a limited set in the core model (for consistency purposes), that said specific types may very well consider their own attributes if needed.

[Denisthemalice]

@fimbault. First of all, thank for your responses.

The two first questions are related to client or end-user collusion attacks where the private key value sharing (or the private key usage sharing) of one client instance is voluntarily performed between two the clients instances.

As far as I understand, the key binding mechanism is NOT resistant to client or end-user collusion attacks.

In the context of long terms RS user accounts, an end-user could voluntarily pass to another end-user an access token and perform either a private key value sharing (or a private key usage sharing). In this way, the other end-user would take benefit of the content of the transmitted access token (whether it is a right or a set of end-user attributes).

The major differences between the key binding approach (called mechanism B earlier) and the "buid" approach (called mechanism A earlier) are that :

• the first one is not resistant to this kind of collusion attack whereas the second one is.
• the first one is slower, since it involves private key signature operations,
• the first one would have several variants (that are not part of the core protocol) whereas the second one would have no variant and would be part of the core protocol

The last answer you gave is the following :

We cover a limited set in the core model (for consistency purposes), that said specific types may very well consider their own attributes if needed.

Such a statement is written nowhere in draft-07.

[fimbault]

I don't know what collusion attacks you're referring to. Those keys are not exposed to end-users. And there exists mitigations against those types of risks (ex hardware protection). Section 12.2 provides necessary details.

[aaronpk]

In the context of long terms RS user accounts, an end-user could voluntarily pass to another end-user an access token and perform either a private key value sharing (or a private key usage sharing). In this way, the other end-user would take benefit of the content of the transmitted access token (whether it is a right or a set of end-user attributes). ... the first one is not resistant to this kind of collusion attack whereas the second one is.

Your proposal does not prevent this attack. A user can still give their access token to someone else, even if it has their user ID in the access token, and the other person can use it to access resources.

[Denisthemalice]

@fimbault :

Those keys are not exposed to end-users. And there exists mitigations against those types of risks (ex hardware protection). Section 12.2 provides necessary details.

Section 12.2 is about the use of TLS, not about key protection. An end-user would be in position :

• either to voluntarily use a modified client instance and import in it the private key from a genuine client instance,
• or to use a genuine client instance and to modify its software to offer a new interface that would allow that modified client instance to perform all the cryptographic computations that another (modified) client instance would need.

The second case is relevant when the private key cannot be maliciously exported, but can be used without being exported.

Hence this mechanism is not resistant to client collaborative attacks, where two clients are intentionally modified by their end-users to perform one of the two collaborative attacks mentioned above.

@aaronpk :

Your proposal does not prevent this attack. A user can still give their access token to someone else, even if it has their user ID in the access token, and the other person can use it to access resources.

My proposal does prevent this attack.

When Bob's client is getting an access token for a long term RS User account for a given RS, it gets in it a guid parameter that contains a guid type and let us say the value "guid_Bob_1234567".

If Alice has opened for a long term RS User account on the same RS, such RS User account will have ben opened with an access token with a guid parameter that contained a guid type and let us say the value "guid_Alice_7654321".

If Bob transmits one of its access tokens valid for his long term user account, it will contain a guid type and let us say the value "guid_Bob_1234567". Such access token will not be accepted on the long term RS user account previously opened by Alice, since it does not contain the value guid_Alice_7654321" (and possibly the same guid type).

The overall security of this mechanism relies on the way the long term RS User accounts for a given RS are created. Different levels of assurance may be considered.

Let us use an example. Today, when using TLS, I am able to access to my bank account using a 8 digits ID and a 6 digits PIN. Let us suppose that my bank offers me to make a transition to a new access mechanism. The bank may request (through the same TLS channel) an access token issued by some AS(s) that only contains the following attributes: my family name and my first name. If the bank is willing to get a better level of assurance, it may request in addition to these two attributes my date of birth and my home address. A key point is that "a bank needs to know his customer".

[fimbault]

@Denisthemalice yes and no. Section 12.2 does explain why your "keyless" proposal based solely on TLS doesn't work. But there are further details which might be of interest to you.

How do you expect end-users to carry out those attacks, unless they use purposely built clients to make this possible ?

[Denisthemalice]

@fimbault.

How do you expect end-users to carry out those attacks, unless they use purposely build clients to make this possible ?

Your request contains the response.

Some skilled developer might develop such purposely build clients and make them available to the community (with or without payment). This means that non-skilled end users might then take advantage of them. As soon as such developments will be made available to the public, the security architecture of draft-07 will collapse.

[fimbault]

Ok. Now how does your proposal solve any of this ?

[jricher]

@Denisthemalice your statements demonstrate that you do not have a correct understanding of how TLS works. The scenario that you describe happening at your bank does not happen that way at all. I recommend that you learn more about how these technologies function in practice.

At this point, I strongly suggest that you implement what you're talking about here and demonstrate your approach. This will conclusively show whether it works.

[Denisthemalice]

@fimbault . At this point of time, I would recommend that you read again draft-pinkas-gnap-core-protocol-00 which contains a full description of the mechanism. Since this draft does not make use of client instance keys, an attack on or a modification of clients to make use of such keys cannot be performed. Instead of using client instance keys, the draft is using an authentication exchange between the end-user and the AS.

@jricher . It is unnecessary to use insults like "you do not have a correct understanding of how TLS works" or "I recommend that you learn more about how these technologies function in practice". Please, moderate your language.

I thank you for your suggestion, but I am not a developer (as you are).

At this point of time, nobody has yet not demonstrated that the approach I am proposing for long term RS user accounts would not work.

I also believe it is important to explain how a transition from an ID/password mechanism to another mechanism can be made. At this point of time, such a transition is not explained in draft-07. For the mechanism I am proposing, it is explained in an earlier post.

[jricher]

@Denisthemalice it is not an insult, the statements that you make above are demonstrably incorrect. I am encouraging you to learn how the systems you're describing work before you continue to make incorrect claims about them. It is my goal that you have the correct information and can therefore draw appropriate conclusions from it. I am sorry that you find this insulting.

It has been demonstrated many times, in this very thread and elsewhere, that your proposal does not solve what you claim it does. The burden is on you to prove that it works. This is why I'm encouraging you to implement what you claim. Show everyone that it works and how it works and you'll have more of a leg to stand on.

[Denisthemalice]

@jricher. If you believe that something is incorrect, unless simply saying that it is incorrect, you had better to explain why it is incorrect.

In the case of draft-07, I have explained how a collaborative / collusion attack could be performed. In the case of draft-00, it is now up to you to explain how a collaborative / collusion attack could be performed.

[jricher]

I already did: Alice hands her token to Bob, Bob uses it to get Alice's stuff.

[Denisthemalice]

The explanations are above. I copy them again:

When Bob's client is getting an access token for a long term RS User account for a given RS, it gets in it a guid parameter that contains a guid type and let us say the value "guid_Bob_1234567".

If Alice has opened for a long term RS User account on the same RS, such RS User account will have ben opened with an access token with a guid parameter that contained a guid type and let us say the value "guid_Alice_7654321".

If Bob transmits one of its access tokens valid for his long term user account, it will contain a guid type and let us say the value "guid_Bob_1234567". Such access token will not be accepted on the long term RS user account previously opened by Alice, since it does not contain the value guid_Alice_7654321" (and possibly the same guid type).

The overall security of this mechanism relies on the way the long term RS User accounts for a given RS are created. Different levels of assurance may be considered.

Let us use an example. Today, when using TLS, I am able to access to my bank account using a 8 digits ID and a 6 digits PIN. Let us suppose that my bank offers me to make a transition to a new access mechanism. The bank may request (through the same TLS channel) an access token issued by some AS(s) that only contains the following attributes: my family name and my first name. If the bank is willing to get a better level of assurance, it may request in addition to these two attributes my date of birth and my home address. A key point is that "a bank needs to know his customer".

Alice is unable to use Bob's access token.

[aaronpk]

@Denisthemalice literally Alice is able to use Bob's token if Bob gives it to Alice. Of course the token will look like Bob's token rather than Alice's token. You still haven't described how the system can prevent the token from being used.

Including a user identifier in an access token is not a unique or novel concept. This is already described today by specs such as the JWT profile for OAuth access tokens, and is common in practice prior to the publication of that specification as well.

If this is your proposal then we can close the issue since there is nothing new being added to the conversation.

[Denisthemalice]

@aaronpk . Please look again at the title of this thread. It is about "Short term and long term RS user accounts".

All the last exchanges are in the context of long term RS user accounts", a concept that does not currently exist in draft-07. A long term RS user account is necessarily associated with one and only one guid/iss pair when the account becomes accessible using this mechanism.

Any next access token for that long term RS user account, in order to be accepted, MUST contain the same guid/iss pair as the one used to create that long term RS user account, otherwise it will be rejected.

Alice could certainly impersonate Bob when using a Bob 's access tokens but only on Bob's RS user account, but she will never be able to take advantage _for her own RS_ user account of an access token issued to Bob.

In the example of the reservation of a train ticket, Alice can open either a short term or a long term RS user account, but she will never be able to get advantage for her own RS user account of an access token issued to Bob that would contain an attribute stating that he is over 60. Hence she will not get the rebate for passengers over 60.

Then you wrote:

Including a user identifier in an access token is not a unique or novel concept. This is already described today by specs such as the JWT profile for OAuth access tokens, and is common in practice prior to the publication of that specification as well.

The JWT profile for OAuth access tokens mandates the "sub" claim to be present but does not specify on how it should be checked by the RS. In the mechanism I am proposing, the way it SHALL be checked is fully specified. This makes a difference.

The other major difference with OAuth is that the content of that "sub" claim is at the discretion of the AS, whereas the type of guid is at the discretion of the end-user. Hence, the end-user is able to tell to the RS whether it is willing to open a short term or a long term RS user account (which is currently unspecified when using the JWT profile for OAuth access token).

[jricher]

@Denisthemalice Then it sounds like what you really want to do is propose an addition or further profile of the JWT Access Token profile to account for different kinds of subject identifiers.

[aaronpk]

The JWT profile for OAuth access tokens mandates the "sub" claim to be present but does not specify on how it should be checked by the RS. In the mechanism I am proposing, the way it SHALL be checked is fully specified. This makes a difference.

Whether and how a sub claim is validated is extremely dependent on a particular deployment of an RS. In some cases the sub claim is irrelevant, in others not. This is not something that can be mandated in a particular way by a spec since it depends on what the end goal is. For example, some RSs may allow any valid user at the AS to access the resource, in which case the value of the sub is irrelevant as long as the access token is verified that it was issued by the trusted AS.

in order to be accepted, MUST contain the same guid/iss pair as the one used to create that long term RS user account, otherwise it will be rejected

You still haven't explained how the RS can know to reject this token. What is it comparing the values of the incoming access tokens to in order to know whether to reject it?

In the example of the reservation of a train ticket, Alice can open either a short term or a long term RS user account, but she will never be able to get advantage for her own RS user account of an access token issued to Bob that would contain an attribute stating that he is over 60. Hence she will not get the rebate for passengers over 60.

This is a design decision of a particular RS and AS that chooses to implement such a feature by putting claims like "over 60" in an access token. If your intent is to mandate that all GNAP systems do this, I suspect you will not get much support for that.

The concept of short term vs long term accounts is not something that every deployment even wants to have, and it cannot be forced on them, since they will just use other specs if that becomes mandatory.

[fimbault]

The long vs short account seems a bit fuzzy, and it doesn't seem obvious to me why people would actually use it. It looks like additional complexity, and I still fail to see what it really brings. Any additional cognitive burden on the end-user must be duly justified IMHO (and to clarify my view, I don't think it's the case here)

[Denisthemalice]

@aaronpk .

You wrote:

Whether and how a sub claim is validated is extremely dependent on a particular deployment of an RS. In some cases the sub claim is irrelevant, in others not. This is not something that can be mandated in a particular way by a spec since it depends on what the end goal is. For example, some RSs may allow any valid user at the AS to access the resource, in which case the value of the sub is irrelevant as long as the access token is verified that it was issued by the trusted AS.

The "buid" (Binding User IDentifier) claim I am proposing is not a replacement of the "sub" (Subject) claim, but a new claim. We could say that, if upon the request from the client, a "buid" claim is inserted by an AS into an access token, then it shall be handled this way by the AS and that way by the RS. This would still allow the use of bearers tokens if such tokens are still requested by some clients ... and still accepted by some RSs.

You wrote:

You still haven't explained how the RS can know to reject this token. What is it comparing the values of the incoming access tokens to in order to know whether to reject it?

When an access token contains a "buid" claim, the RS should first check whether the issuing AS is part of the ASs that it trusts for some attribute types and/or some methods (in the case of capabilities). If a signature validated access token is issued from one of these ASs, the RS SHALL first compare the value of the "buid" claim contained in the access token with the "buid" values already stored by the RS and associated with RS User accounts.

• If a match is found, then the access token is associated with that RS user account.
• If no match is found, then a new RS user account is created.

Then after the attributes and/or the capabilities contained in the access token, are associated with the RS User account, if and only if, the issuing AS is trusted to issue such attribute types and/or such methods (in the case of capabilities).

To answer to your question, there is no "access token rejection", but the access token is either associated with the "appropriate" RS user account or the "buid" claim contained in the access token is used to create a new RS user account. Is it becoming clear now ?

You wrote:

If your intent is to mandate that all GNAP systems do this, I suspect you will not get much support for that.

The concept of short term vs long term accounts is not something that every deployment even wants to have, and it cannot be forced on them, since they will just use other specs if that becomes mandatory.

OK. I understand. Since the inclusion of a "buid" claim is made upon the request from a user/client, if the user/client does not make such a request, there will be no "buid" claim in it. IMO, the implementations SHALL be able to support the "buid" claim, but applications may or may not use this feature. Would such a proposal be acceptable ?

[Denisthemalice]

@fimbault . I am sorry. I forgot to answer to your question which was:

The long vs short account seems a bit fuzzy, and it doesn't seem obvious to me why people would actually use it. It looks like additional complexity, and I still fail to see what it really brings.

The answer is quite simple. It corresponds to a current situation. If you make a reservation on a web site like https://www.oui.sncf/ you have two options:

• create a long term user account by choosing a password for the web site (while the ID will be your email address) and disclose your family name, first name, home address and phone number(s), which will be memorized by the web site, so that the next time you want to use this web site you don't need to enter again, your family name, first name, home address and phone number(s), or
• use a short term user account that will be valid only during your train/flight/ hotel/car reservation(s) so that the next time you want to use this web site you will need to enter again your family name, first name, home address and phone number(s).

In the first case, the web site keeps track of your family name, first name, home address and phone number(s) which are associated with your long term user account. On the contrary, the use of the short term user account is terminated at the end of your reservations.

[fimbault]

This may apply to payments / ecommerce, but are there other use cases ?

[Denisthemalice]

This applies to "C to B transactions" in general.