fimbault
commented
2 years ago Ok, I understand the business logic. But whether there should be a distinction in the authorization layer is an other story.
If summarize what you're saying : in the cases where there's long term RS account, we might use an additional attribute referencing that RS account.
As far as I understand it :
- it doesn't alleviate all impersonation issues (as already discussed above)
- it's not entirely clear how this attribute is known by the AS, without managing even more personal data (i.e a mapping of RS locations / buid for each subject)
Denisthemalice
jricher
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:
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:
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.