I think Torsten did the example with "debtorAccount" so he can maybe provide more insight into what he was trying to convey with it. But I interpreted it similar to Kai in it being more akin to the sub and about the user's account in general rather than the specific transaction. The text "selected by the user during the authorization process" does kinda suggest it would be better treated as enriched authz details though. So yeah, I agree that it is potentially somewhat confusing. But it's not necessarily wrong or right - either can work and it's ultimately up to the design of the API .
On Mon, Jun 12, 2023 at 3:54 AM Kai Lehmann <kai.lehmann= 401und1...@dmarc.ietf.org> wrote: > Hi again, > > > > ok I understood your concern better now. I think the authors should be > able to answer that better, but I believe it depends on whether the > information the RP actually needs compared to what information a RS would > need in order to fulfill the operation. For example, when a client would > like to request the authorization for a SEPA mandate, the client wants to > know the bank account identifier and would ask for it within the > authorization_details in the request. When it comes to performing a > one-time transfer to a specific creditor account, on the other hand, the > client would provide the creditor account number, the amount and maybe a > payment reference number. The client does not care about where the money is > coming from as long as it is being transferred to the target account. > However, the RS which is actually performing the transfer operation may > need this. > > > > /Kai > > > > *From: *"Oliva Fernandez, Jorge" <Jorge.OlivaFernandez= > 40santander.co...@dmarc.ietf.org> > *Date: *Monday, 12. June 2023 at 11:21 > *To: *Kai Lehmann <kai.lehm...@1und1.de>, "Oliva Fernandez, Jorge" < > jorge.olivafernan...@santander.co.uk>, "oauth@ietf.org" <oauth@ietf.org> > *Subject: *Re: Re: [OAUTH-WG] RFC 9396 - RAR doubt about examples > > > > Hi Kai, and thanks for your response, > > > > The thing is that in section 9.1 say this in the description of the > “debtorAccount”: > > > > ”In the example, this account was not passed in the authorization_details but > was selected by the user during the authorization process.” > > > > Seems for me that the “debtorAccount” meet the requiements of your > sentence “The authorization details, on the other hand, contain > information which the End-User authorizes interactively.” And if the > “debtorAccount” has been selected in the authorization process is not this > exactly what is described in section “7.1. Enriched Authorization Details > in Token Response” in example of Figure 17? > > > > Best regards. > > > > *From: *OAuth <oauth-boun...@ietf.org> on behalf of Kai Lehmann > <kai.lehmann=401und1...@dmarc.ietf.org> > *Date: *Monday, 12 June 2023 at 09:22 > *To: *"Oliva Fernandez, Jorge" <Jorge.OlivaFernandez= > 40santander.co...@dmarc.ietf.org>, "oauth@ietf.org" <oauth@ietf.org> > *Subject: *[EXT]Re: [OAUTH-WG] RFC 9396 - RAR doubt about examples > > > > *CAUTION:* This message is from an EXTERNAL sender – be vigilant, > particularly with links and attachments. If you suspect it, report it > immediately using the phishing button. > > 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] > > 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 > -- _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you._
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
