All, As the shepherd for this document, I have reviewed the latest version of the draft https://www.ietf.org/archive/id/draft-ietf-oauth-identity-chaining-06.html
I have the following comments/questions: Section 2.1 It would be great if a sentence or two are added to explain why the initial interaction in domain A is limited to token exchange. Section 2.1, bullet (C) where domain B's authorization server trusts the public key(s) of domain A > to sign JWT authorization grants I think I understand what this sentence is trying to say, but I think it needs to be reworded, because you cannot use public keys to sign a JWT. Section 2.3.2, first bullet It would be great if you can add a reference to a document that explicitly defines which error code would be used to deny the request. Section 2.4.1, 3rd bullet You might want to add some text to explain ‘scope’ Section 2.4.2, second bullet It would be great if you can add a reference to a document that explicitly defines which error code would be used to deny the request. Section 2.5, last bullet The populated claims SHOULD be namespaced or validated to prevent the > injection of invalid claims. Can you elaborate on this sentence? Section 3 Authorization servers MAY choose not to advertise some supported requested > token types… What would be the reasons for doing this? Section 5.1 and 5..2 Why is the use of SHOULD instead of MUST? Section 5.3 The authorization server in trust domain A SHOULD perform client > authentication You might want to elaborate on why this is a SHOULD and not a MUST, to make sure the implementer understands in which cases this is possible and which is not. Section 5.4 The authorization server in trust domain B SHOULD NOT issue refresh tokens > to the client within the scope of this specification. Are there use cases where the AS can issue refresh tokens? If yes, then maybe provide an example, if no, then maybe this should be a MUST NOT? Regards, Rifaat
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
