what is azp really?

Issue #830 resolved
Brian Campbell created an issue

Even though I'm somewhat familiar with how "azp" got in the spec, from kind of knowing about Google's use case of "cid", and sort of know what it's supposed to do, I find the current text in the spec to be pretty confusing.

For example, there's text now for azp that says it "identifies an OAuth 2.0 Client authorized to use this ID Token as an OAuth Access Token." But I don't know what that actually means. There's no way to identify who the client is using an OAuth bearer token. So what does it mean to be authorized? How does one check or enforce that?

That's just one example. Other text that talks about id token validation and I still read it and don't see how it's different than a token w/ more than one audience. Just different with more rules. I know it's been said that this could be used for a HoK type token but we don't have that yet.

I believe that more clarification about what azp really is and what the OP and client are supposed to do with it would be good. As well as other systems and actors.

Folks (George/Nat) on the call (March 28) suggested that it's more aptly described as an "issued to" or "registered to" respectively.

And I still think different people have somewhat different ideas about what this thing is.

Common understanding and clarification would be good.

This issue is admittedly somewhat ticky-tacky but I was asked on the March 28 call to go ahead and file something on it for posterity. So that's what I'm doing.

Comments (6)

  1. Michael Jones

    We agreed to change the word "Client" to "Relying Party" in the audience definition, because that phrasing works better for non-OpenID Connect usages of the ID Token.

    For the rest of this issue to be actionable, specific proposed text would need to be written. John agreed to write some text about the audience and consent.

  2. Nat Sakimura

    At this point, this issue is a dup of #712 . #712 is the thread discussing the actual text and its got various historical discussion on there, so we should continue it there.

  3. Michael Jones

    Fixed #712 - Clarified the "azp" description and made "azp" multi-valued, like "aud". Fixed #830 - Clarified that "aud" of an ID Token must contain the Client ID of the Relying Party.

    → <<cset fd362360436a>>

  4. Log in to comment