Dears,
I'd like to provide some feedback and questions, and in view of the limited 
time in the meeting chose to do it here.


  *   When an ID token is used to request an ID-JAG, I assume its expiration is 
evaluated so that expired ID tokens are rejected? If so and considering limited 
ID token exp (in line with its intended usage to be consumed once by an OpenID 
RP), this reduces this path's interoperability.
  *   I assume that's why you've introduced refresh tokens as subject tokens. 
When a refresh token is successfully used to obtain an ID-JAG, should it be 
rotated?
  *   Including RAR in the ID-JAG token exchange request is a valid use case, 
however it presents some challenges:
     *   The requested authorization_details are expected and enforced by the 
resource domain (and its AS), but requested from the IDP AS and their request 
processing and inclusion is governed by its policies.
     *   How would the IDP AS publish supported authorization_details types and 
their metadata, when it is actually acting as a proxy for the Resource AS?
     *   Perhaps my draft (RAR Metadata and error 
remediation<https://datatracker.ietf.org/doc/draft-zehavi-oauth-rar-metadata/>) 
can support this use case:
        *   Resource AS could use the proposed RAR metadata endpoint to publish 
metadata and schema of its RAR types:
[cid:[email protected]]

        *   This allows IDP AS runtime enforcement of requested 
authorization_details against Resource AS' published schemas.
        *   Furthermore, If Resource AS publishes metadata using schema_uri and 
documentation_uri, then IDP AS may act as a proxy pointing to remote schemas by 
reference, by including remote uris. I assume this will require gating by an 
administrator to configure which remote Resource AS to accept as audience, 
which (scopes and) RAR types of theirs to support and which local policies 
govern their processing.

Regards,
Yaron
This message and any attachment ("the Message") are confidential. If you have 
received the Message in error, please notify the sender immediately and delete 
the Message from your system, any use of the Message is forbidden. 
Correspondence via e-mail is primarily for information purposes. RBI neither 
makes nor accepts legally binding statements via e-mail unless explicitly 
agreed otherwise. Information pursuant to ? 14 Austrian Companies Code: 
Raiffeisen Bank International AG; Registered Office: Am Stadtpark 9, 1030 
Vienna, Austria; Company Register Number: FN 122119m at the Commercial Court of 
Vienna (Handelsgericht Wien).

Classification: GENERAL
_______________________________________________
OAuth mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to