Re: [Ace] Fwd: New Version Notification for draft-ietf-ace-oauth-authz-17.txt and draft-ietf-ace-oauth-params-01.txt

[Stefanie Gerdes <[e-mail]>]

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