Am 13. Juni 2023, 12:02 +0200 schrieb Oliva Fernandez, Jorge
<Jorge.OlivaFernandez=40santander.co...@dmarc.ietf.org>:
Hi Torsten,
Thanks for your answer but this seems still very confused to me, so just let me
put a real use case for RAR and see if I can understand correctly, suppose that
Open Banking (never mind the country) replace the lodging intent pattern with
PAR + RAR, an as already covered by OB, the debtor account is selected in the
Authorization Process where the customer authorize a payment/transfer… Where
should the AS return the “debtorAccount” field in the introspect in order to
allow the RS (or a API gateway) validate the authorization of the operation,
inside the “authorization_details” or as a root field in the JSON response?
both are valid options
Best regards.
From: OAuth <oauth-boun...@ietf.org> on behalf of
"torsten=40lodderstedt....@dmarc.ietf.org"
<torsten=40lodderstedt....@dmarc.ietf.org>
Date: Tuesday, 13 June 2023 at 10:19
To: "Jorge.OlivaFernandez=40santander.co...@dmarc.ietf.org"
<Jorge.OlivaFernandez=40santander.co...@dmarc.ietf.org>
Cc: "oauth@ietf.org" <oauth@ietf.org>, Brian Campbell
<bcampbell=40pingidentity....@dmarc.ietf.org>, Kai Lehmann
<kai.lehmann=401und1...@dmarc.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,
the difference between section 7 and 9 is as Kai described it.
Section 7 is about additional data given to the client in the token response
that is needed to perform the rest of the process. Figure 17, for example,
shows how the authorization details object is enriched with the account
numbers. The client needs this data as, otherwise, it would not know which
resources to access. The way it happens is the enrichment of the authorization
details, which is part of the interoperable interface between AS and client.
Section 9, on the other hand, is about the way the AS shares data with the RS.
This interface is internal within the AS domain and (typically) proprietary. So
the AS does not need to share any data in the form of an authorization details
object, it could use a completely proprietary structure. However, It is
straight forward to share the data as they were passed into the authorization
process (and were potentially enriched in the course of the authorization
process). It didn’t seem to be reasonable to me to do the same with the
debtorAccount data, es this data is purely between AS and RS. No-one outside of
the process will see it.
Bottomline: there is no issue with the examples. Section 9 just shows one way
to implement it, you could use other ways.
best regards,
Torsten.
Am 12. Juni 2023, 19:22 +0200 schrieb Brian Campbell
<bcampbell=40pingidentity....@dmarc.ietf.org>:
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
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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
