Re: [OAUTH-WG] RFC 9396 - RAR doubt about examples

[torsten=40lodderstedt . net]

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 
:
> 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 
> >  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" 
> > > 
> > > Date: Monday, 12. June 2023 at 11:21
> > > To: Kai Lehmann , "Oliva Fernandez, Jorge" 
> > > , "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  on behalf of Kai Lehmann 
> > > 
> > > Date: Monday, 12 June 2023 at 09:22
> > > To: "Oliva Fernandez, Jorge" 
> > > , "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 

Re: [OAUTH-WG] RFC 9396 - RAR doubt about examples

[Oliva Fernandez, Jorge]

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?

Best regards.

From: OAuth  on behalf of 
"torsten=40lodderstedt@dmarc.ietf.org" 

Date: Tuesday, 13 June 2023 at 10:19
To: "Jorge.OlivaFernandez=40santander.co...@dmarc.ietf.org" 

Cc: "oauth@ietf.org" , Brian Campbell 
, Kai Lehmann 

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 
:

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 
mailto: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" 
mailto:40santander.co...@dmarc.ietf.org>>
Date: Monday, 12. June 2023 at 11:21
To: Kai Lehmann mailto:kai.lehm...@1und1.de>>, "Oliva 
Fernandez, Jorge" 
mailto:jorge.olivafernan...@santander.co.uk>>,
 "oauth@ietf.org" mailto: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

Re: [OAUTH-WG] RFC 9396 - RAR doubt about examples

[torsten=40lodderstedt . net]

Am 13. Juni 2023, 12:02 +0200 schrieb Oliva Fernandez, Jorge 
:
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  on behalf of 
"torsten=40lodderstedt@dmarc.ietf.org" 

Date: Tuesday, 13 June 2023 at 10:19
To: "Jorge.OlivaFernandez=40santander.co...@dmarc.ietf.org" 

Cc: "oauth@ietf.org" , Brian Campbell 
, Kai Lehmann 

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 
:

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 
 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" 

Date: Monday, 12. June 2023 at 11:21
To: Kai Lehmann , "Oliva Fernandez, Jorge" 
, "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 R

Re: [OAUTH-WG] RFC 9396 - RAR doubt about examples

[Oliva Fernandez, Jorge]

Ok thanks,

And in the response of the /token endpoint should be inside the 
“authorization_details” as described in the section 7?

Best regards.

From: OAuth  on behalf of 
"torsten=40lodderstedt@dmarc.ietf.org" 

Date: Tuesday, 13 June 2023 at 11:45
To: "torsten=40lodderstedt@dmarc.ietf.org" 
, 
"Jorge.OlivaFernandez=40santander.co...@dmarc.ietf.org" 
, "Oliva Fernandez, 
Jorge" 
Cc: "oauth@ietf.org" , Brian Campbell 
, Kai Lehmann 

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.
Am 13. Juni 2023, 12:02 +0200 schrieb Oliva Fernandez, Jorge 
:

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  on behalf of 
"torsten=40lodderstedt@dmarc.ietf.org" 

Date: Tuesday, 13 June 2023 at 10:19
To: "Jorge.OlivaFernandez=40santander.co...@dmarc.ietf.org" 

Cc: "oauth@ietf.org" , Brian Campbell 
, Kai Lehmann 

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 
:
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 
mailto: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" 
mailto:40santander.co...@dmarc.ietf.org>>
Date: Monday, 12. June 2023 at 11:21
To: Kai Lehmann ma

Re: [OAUTH-WG] RFC 9396 - RAR doubt about examples

[torsten=40lodderstedt . net]

The token response is different as this is part of the interface between AS and 
client, i.e. there needs to be rules in place so both parties can interoperate.

OAuth has traditionally always focused on client to AS and client to RS for 
interoperability and left out AS to RS from the equation.

best regards,
Torsten.
Am 13. Juni 2023, 13:13 +0200 schrieb Oliva Fernandez, Jorge 
:
> Ok thanks,
>
> And in the response of the /token endpoint should be inside the 
> “authorization_details” as described in the section 7?
>
> Best regards.
>
> From: OAuth  on behalf of 
> "torsten=40lodderstedt@dmarc.ietf.org" 
> 
> Date: Tuesday, 13 June 2023 at 11:45
> To: "torsten=40lodderstedt@dmarc.ietf.org" 
> , 
> "Jorge.OlivaFernandez=40santander.co...@dmarc.ietf.org" 
> , "Oliva Fernandez, 
> Jorge" 
> Cc: "oauth@ietf.org" , Brian Campbell 
> , Kai Lehmann 
> 
> 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.
> Am 13. Juni 2023, 12:02 +0200 schrieb Oliva Fernandez, Jorge 
> :
>
> > quote_type
> > 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
> > quote_type
> >
> > Best regards.
> >
> > From: OAuth  on behalf of 
> > "torsten=40lodderstedt@dmarc.ietf.org" 
> > 
> > Date: Tuesday, 13 June 2023 at 10:19
> > To: "Jorge.OlivaFernandez=40santander.co...@dmarc.ietf.org" 
> > 
> > Cc: "oauth@ietf.org" , Brian Campbell 
> > , Kai Lehmann 
> > 
> > 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 
> > :
> > > quote_type
> > > 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 
> > >  wrote:
> > > > quote_type
> > > > 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 
> > >