Hi Oliva,

I don’t see inconsistencies. As far as I understand it, the debtorAccount is 
information about the authenticated user account. This is information which the 
RS may need in order to know where the money needs to be transferred FROM. This 
is nothing which the End-User can change as the account is tied to the user 
account. It’s similar to the “sub” which is an identifier of the user account 
at the AS. However, the RS may not understand the sub as it only deals with 
bank account identifiers (IBANs). The AS does know the relation between sub and 
bank account of the End-User and thus can provide the bank account information 
of the End-User in the JWT (or Token Introspection response) to the RS. The 
authorization details, on the other hand, contain information which the 
End-User authorizes interactively. In this case, it contains the information of 
the bank account the money is transferred TO and of course the amount of the 
transferred money.

Best,
Kai


From: OAuth <oauth-boun...@ietf.org> on behalf of "Oliva Fernandez, Jorge" 
<Jorge.OlivaFernandez=40santander.co...@dmarc.ietf.org>
Date: Monday, 12. June 2023 at 10:08
To: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] RFC 9396 - RAR doubt about examples

Hi,

Any comment about this? Thanks!

Best regards.

From: "Oliva Fernandez, Jorge" <jorge.olivafernan...@santander.co.uk>
Date: Friday, 2 June 2023 at 14:10
To: "oauth@ietf.org" <oauth@ietf.org>
Subject: RFC 9396 - RAR doubt about examples

Hi,

Reviewing the just releases RFC there are a couple of examples that seems 
incorrect or maybe I’m missing something, in section 9.1 and 9.2 appear a field 
“debtorAccount” outside the “authorization_details” object and in section 9.1 
specify:

“debtorAccount:
API-specific field containing the debtor account. In the example, this account 
was not passed in the authorization_details but was selected by the user during 
the authorization process. The field user_role conveys the role the user has 
with respect to this particular account. In this case, they are the owner. This 
data is used for access control at the payment API (the RS).
”

If this “debtorAccount” is the result of an “Enriched Authorization Details“ 
should not follow what is described in section 7.1 and be returned inside the 
“authorization_details” Object?

Best regards.
Emails aren't always secure, and they may be intercepted or changed after 
they've been sent. Santander doesn't accept liability if this happens. If you 
think someone may have interfered with this email, please get in touch with the 
sender another way. This message doesn't create or change any contract. 
Santander doesn't accept responsibility for damage caused by any viruses 
contained in this email or its attachments. Emails may be monitored. If you've 
received this email by mistake, please let the sender know at once that it's 
gone to the wrong person and then destroy it without copying, using, or telling 
anyone about its contents.
Santander UK plc. Registered Office: 2 Triton Square, Regent's Place, London, 
NW1 3AN, United Kingdom. Registered Number 2294747. Registered in England and 
Wales. https://www.santander.co.uk. Telephone 0800 389 7000. Calls may be 
recorded or monitored. Authorised by the Prudential Regulation Authority and 
regulated by the Financial Conduct Authority and the Prudential Regulation 
Authority. Our Financial Services Register number is 106054. You can check this 
on the Financial Services Register by visiting the FCA’s website 
https://www.fca.org.uk/register.  Santander and the flame logo are registered 
trademarks.
Ref:[PDB#1-4B]
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Reply via email to