Hi, I looked through the document again. Many issues have been fixed, but I still have some comments:
I still think that Section 5.8.1, in particular 5.8.1.1 should point out that RS must check the integrity of the token und validate that it stems from an authorized AS. Checking the iss field does not help in this case and I don't see much value in this check; cryptographic assurance such as AS' signature or MAC of the token is required to ascertain the authenticity, and in this case the issuer, of the token. 5.8.1. exiting -> existing Section 5.8.1. states that RS must check that the expiration time given in the exp field is in the future. This is difficult if the RS is not time synchronized. Option 3 in section 5.8.3 seems to suggest that this field is not always required. Instead of demanding that the exp field is checked the document should demand that the RS somehow validates that the token is not expired. Checking the exp field may be one example. C may receive keying material for the communication with RS from AS. Unfortunately, the AS does not inform C how long the keying material is valid. C therefore may use outdated keying material for the communication. C cannot rely on RS to reject messages that were sent with outdated keying material because 1. the information in the request sent by C may be confidential and is then compromised and 2. C cannot be sure that it is actually communicating with the intended RS if the keying material is no longer valid. I did not find any indication how the client knows how to choose the correct req_aud for RS. The document must point out that C may communicate with the wrong RS unless C and AS have a common understanding how RS is identified. Viele Grüße Steffi _______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
