On Mon, Nov 4, 2013 at 10:45 AM, Brian Campbell <[email protected]>wrote:
> On Fri, Nov 1, 2013 at 1:52 PM, Hannes Tschofenig > <[email protected]> wrote: > > You write: > > > > " > > 3. The JWT MUST contain an "aud" (audience) claim containing a > > value that identifies the authorization server as an intended > > audience. The token endpoint URL of the authorization server > > MAY be used as a value for an "aud" element to identify the > > authorization server as an intended audience of the JWT. JWTs > > that do not identify the authorization server as an intended > > audience MUST be rejected.... > > " > > > > If the endpoint URL of the AS is not used then what else? Wouldn't it be > > useful to say "The token endpoint URL of the authorization server > > MUST be used as a value for an "aud" element to identify the > > authorization server as an intended audience of the JWT."? > > This and the other assertion documents offer the token endpoint URL as > one way to identify the AS for deployments which lack some other means > of doing so. However, these assertion profiles are little slices of > functionality that augment existing deployments of OAuth, often in > conjunction with other 'federated' technologies for which there will > be an existing and agreed upon identifier that the issuer is known by. > This is not just academic - it's how these systems and deployment > already work. It's inappropriate and unrealistic for this document (or > the other assertion docs) to preclude common and useful deployment > practices. > Agreed. > > > Then, I have a suggestion for re-phrasing this sentence from : > > " > > Audience values SHOULD be compared > > using the Simple String Comparison method defined in Section > > 6.2.1 of RFC 3986 [RFC3986], unless otherwise specified by the > > application. > > " > > to: > > > > " > > In the absence of an application profile standard specifying > > otherwise, a compliant JWT Bearer application MUST compare the audience > > values using the Simple String Comparison method defined in Section > > 6.2.1 of RFC 3986 [RFC3986]. > > " > > I think I'm okay with that re-phrasing. Do others (my co-authors > especially) agree? Or object? > I'm good with it. -cmort > > > > > The same can actually be applied to the issuer claim as well. > > As I said in the previous mail about issuer, I'd like to get rid of > the comparison text. However, if such text stays, I'll work to make it > consistent throughout. > > > Given that the JWT had been updated to align it with the JOSE work I > suspect > > that this document also requires an update. > > You may well be correct. But despite following the JOSE and JWT work, > I'm not sure I know what update(s) would be required. Can you > elaborate? > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
