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]