Identify user associated to the access token

[bitbucket-import-issues]

Originally submitted by pameladingle (Pamela Dingle) on 2017-03-23

The read-only spec section 6.2.1 says a resource server "shall identify the associated user to the access token;". But what if the subject isn't a user? What if this particular request is from a legitimate non-human subject?, such as a client application making a B2B call? It is perfectly valid for API security regimes to use 2-legged schemes to access financial APIs, is this simply considered out of scope?

---

Bitbucket status: resolved

Bitbucket origin: issue 81

[bitbucket-import-issues]

Originally submitted by josephheenan (Joseph Heenan) on 2017-03-23

Should we use the X.1254 language of 'entity' instead of 'user'?

The authentication is done by the bank, so I believe it is up to the bank whether they allow an non-human subject access to an account. (At least in the UK, I believe money laundering regulations require that all [write] account access is authorised by a human.)

[bitbucket-import-issues]

Originally submitted by tomcjones (Tom Jones) on 2017-03-23

There seems to be a plethora of names that are related but are not well defined: resource owner, customer, user, end-user, client, client application. In Pam's comment I cannot tell whether the client application is a user agent or just some random service that has an authz token. In financial accounts it is typical to discuss the account owner, which is often not a human and one or more authorized agents. In many countries the authorized agent is required to be a human, but that human might be a comptroller who has further delegated authority to mechanical process and seldom signs any checks on his own.

In regard to whether a user is a human or not, that is, in principle, not known for LOA 2. Only in LOA 4 can we be assured that the user is a human. In other cases it would be a violation of privacy principles to even ask the question. But of course that is exactly what a CAPTCHA tries to do for reasons unrelated to privacy.

I suspect that the relations between the various entities involved are more clearly enumerated in the spec.

• customer = resource owner = account owner (perhaps just eliminate the term customer?)
• user = agent = the legal person that has the authority over the account (implies human in some jurisdictions)
• impersonation = a process that is authorized by the authority to act on their behalf (even tho that is what a client is in RFC 6749, there may be non-openid agents that need to acquire authz tokens.)

As an aside I have yet to hear of a human that is actually wired into the internet. They all seem to be employing user agents.

[bitbucket-import-issues]

Originally submitted by SaschaZeGerman (Sascha Preibisch) on 2017-03-28

Regarding Pamela's comment, I think 'user' is simply the entity that has granted the access_token. If its a resource_owner (to use an oauth term) or a client (to use another oauth term) does not really matter. In any case the resource server has to somehow retrieve that information of the authorization server that has issued the access_token unless it is a self contained access_token such as a JWT.

Regarding Tom's comment, 'user agent' usually refers to a browser. And on that note, if you ask my wife, she would say that I, as a human, am more or less wired to the internet too ... yes.
But I agree that only a reduced number of terms should be used, ideally hijacked from other specs such as OAuth 2.0 and OpenID Connect.

[bitbucket-import-issues]

Originally submitted by tomcjones (Tom Jones) on 2017-03-28

The language of the existing OpenID specs is not well suited to the
purposes of the FAPI. The resource owner of the data is the FI, not the
user. If it is a payment the money is held by the FI as a fiduciary agent
for the account owner, who may not be the user.

In order to keep these concepts clear i think that the first lesson should
be that the read/write spec should not attempt to deal with payments, but
only with account information. That would mean that the read/write spec
should not address any financial transactions what-so-ever.

Note that this does not mean that the data sent in the read-write protocol
does not create potential financial liability. Consider the entry of a
payee. That would allow a future transaction to make a payment request that
was bogus. It would actually improve security for separation of duties to
prevent the same transaction to create a payee and create a payment. That
is approximately what happens in existing FI web site. A similar separation
occurs on Amazon where the creation of a ship-to address changes the nature
of a pending order transaction.

[bitbucket-import-issues]

Originally submitted by josephheenan (Joseph Heenan) on 2017-03-29

The feeling from the call seems to be that 'user' should become 'entity', but we need to review whether it makes sense to change other instances of user to entity.

[bitbucket-import-issues]

Originally submitted by tomcjones (Tom Jones) on 2017-03-29

The IDESG has taken a different approach and stated that the human user is
specifically not an entity. I personally believe that a distinction between
carbon based life forms and other entities is critical to success.

Sorry I missed the call, I Never heard what the decision on the the time
zone was.

..tom

thx ..Tom (mobile)

[bitbucket-import-issues]

Originally submitted by Nat (Nat Sakimura) on 2017-04-04

The callers came to a consensus that entity is fine.

Waiting for a pull request.

[bitbucket-import-issues]

Originally submitted by Edmund Jay (Edmund Jay) on 2017-12-20

→ <>