client to ensure AAG audience makes sense

[bc-pi]

To fix #13

Advise the client to ensure that the audience of an assertion authorization grant (AAG) makes sense with respect to where it’s being sent.

See it rendered here https://drafts.oauth.net/draft-ietf-oauth-rfc7523bis/13-client-responsible/draft-ietf-oauth-rfc7523bis.html

[bc-pi]

looks like this would cover these two from #14 too:

not sure an update from https://saml-sp.example.net/ to https://authz.example.net/ in the SAML is needed.

and

not sure an update to the whole SAML 2.0 Assertion example is needed

[selfissued]

This deletes the text saying that "The audience value MUST identify the authorization server as the intended audience." This seems like a regression.

[bc-pi]

This deletes a number of things including the replacement of RFC7521 Section 5.2 so the replacement text is now only updating the metamodel description of the Audience parameter in RFC7521 Section 5.1.

That leaves the text RFC7521 Section 5.2 General Assertion Format and Processing Rules in place:

o The assertion MUST contain an Audience that identifies the
authorization server as the intended audience. The authorization
server MUST reject any assertion that does not contain its own
identity as the intended audience.

[selfissued]

I disagree with deleting the updated example. Having it is useful to readers.

[bc-pi]

In what way is it useful to readers to include a lot of unnecessary intimidating/ugly/arcane XML content to replace a perfectly legitimate example ?

[selfissued]

In my view, our spec should be replacing all the sections of the specs that it updates that we regard to be a bad practice with respect to the vulnerability. The current published draft already does so. Removing this update to the example would mean that we're no longer doing that, which would be a regression.

[panva]

Surely we are not replacing entire sections every single time. To that end I am not seeing removing an example from an update that deprecates a particular portion of a spec as a regression.

[bc-pi]

In my view, our spec should be replacing all the sections of the specs that it updates that we regard to be a bad practice with respect to the vulnerability.

But there is no problem with using the SAML Entity ID, which is what https://www.rfc-editor.org/rfc/rfc7522#section-4 that this would replace does. No change is needed.

[selfissued]

This weakens the requirement that the authorization server be identified as the audience of the token.

[bc-pi]

The text just above is still there https://github.com/oauth-wg/draft-ietf-oauth-rfc7523bis/pull/18/files#diff-f8b056b1a56bc0092e4789b332d277014a437a10e97bfc70483936f5734187caR246

  The JWT MUST contain an <spanx style="verb">aud</spanx>
  (audience) claim containing a value that
  identifies the authorization server as the intended audience.
  Two cases are differentiated:

[selfissued]

I disagree with deleting "The audience value MUST identify the authorization server as the intended audience." This seems like a regression.

I also disagree with deleting the SAML example, since it is useful to readers.

[panva]

I disagree with deleting "The audience value MUST identify the authorization server as the intended audience." This seems like a regression.

I also disagree with deleting the SAML example, since it is useful to readers.

I'm torn on doing anything to the SAML grant beyond just saying it SHOULD NOT be used. The least of which is updating non-normative and difficult to parse examples.