> On 25. Aug 2020, at 18:26, Denis <denis.ietf@xxxxxxx> wrote: > > Here is an additional comment: > > The text mentions in the Introduction: > > In example is a resource server using verified person data > to create certificates, which in turn are used to create qualified > electronic signatures. > > The problem is the following: the AS has no way to verify that the User has effectively authorized the RS > to use the JWT Response for such a purpose. A "User Consent" phase for such a usage has not been addressed. Why not? The AS can easily ask the resource owner/user in the authorization process for consent to transfer certain end user claims to the RS. As a pre-requisite, the AS needs to determine what data is transmitted to an RS for a certain scope. > > This concern is identified in RFC 6973 as: > > 5.2.3. Secondary Use > > Secondary use is the use of collected information about an individual > without the individual’s consent for a purpose different from that > for which the information was collected. Secondary use may violate > people’s expectations or desires. The potential for secondary use > can generate uncertainty as to how one’s information will be used in > the future, potentially discouraging information exchange in the > first place. Secondary use encompasses any use of data, including > disclosure. > > The progression of this draft is really questionable. The User has currently no way to allow or to disallow this protocol > which is between a RS and an AS. It would not be reasonable to say that this concern is outside the scope of this draft. > Denis This is no secondary use, it’s the primary use the user consented with. > > > >> This draft contains a "Privacy considerations" section (Section 9). >> . >> The content of this section is as follows: >> >> The token introspection response can be used to transfer personal >> identifiable information from the AS to the RS. The AS MUST ensure a >> legal basis exists for the data transfer before any data is released >> to a particular RS. The way the legal basis is established might >> vary among jurisdictions and MUST consider the legal entities >> involved. >> >> For example, the classical way to establish the legal basis is by >> explicit user consent gathered from the resource owner by the AS >> during the authorization flow. >> >> It is also possible that the legal basis is established out of band, >> e.g. in an explicit contract or by the client gathering the resource >> owner’s consent. >> >> If the AS and the RS belong to the same legal entity (1st party >> scenario), there is potentially no need for an explicit user consent >> but the terms of service and policy of the respective service >> provider MUST be enforced at all times. >> >> In any case, the AS MUST ensure that the scope of the legal basis is >> enforced throughout the whole process. The AS MUST retain the scope >> of the legal basis with the access token, e.g. in the scope value, >> and the AS MUST determine the data a resource server is allowed to >> receive based on the resource server’s identity and suitable token >> data, e.g. the scope value. >> >> It is not believed that these explanations are useful, nor sufficient. >> >> Talking a "legal basis" without translating legal constraints into technical constraints is not useful. >> Since sensitive information may be returned, the text should say that AS should/must make sure that the requesting RS is indeed >> authenticated and allowed to perform this operation. >> >> However, section 4 is only using the verb "SHOULD" whereas it should use the verb "SHALL" : >> The AS SHOULD authenticate the caller at the token introspection endpoint. >> Talking of "an explicit user consent gathered from the resource owner by the AS" does not make sense. >> Either the operation is allowed or is not allowed by the RO, but there is no "RO consent". >> >> About RFC 7662 (OAuth 2.0 Token Introspection) >> >> One might think that the important considerations have already been provided when issuing RFC 7662 (OAuth 2.0 Token Introspection) >> which contains a Privacy considerations section (section 5). >> >> The third sentence states: >> One method is to transmit user identifiers as opaque service-specific strings, potentially returning different identifiers to each protected resource. >> This would mean that the response would not reflect the content of the token. Furthermore, the RS would not even be informed of such a transformation. >> >> The last sentence even states: >> Omitting privacy-sensitive information from an introspection response is the simplest way of minimizing privacy issues. >> In such a case, the introspection query becomes more or less useless. >> >> What should have been said in RFC 7662 (OAuth 2.0 Token Introspection) ? >> >> The fact that using an introspection call can be avoided and should be avoided for privacy reasons. While "in OAuth 2.0 [RFC6749], >> the contents of tokens are opaque to clients", it is not opaque to RSs. As soon as the RS knows the format of the access token and is able >> to validate its security features, this call should be avoided. >> >> So what should be mentioned in section 9 ? >> >> The fact that the AS will know exactly when the introspection call has been made and thus be able to make sure which client >> has attempted perform an access to that RS and at which instant of time. The use of this call allows an AS to track where and when >> its clients have indeed presented an issued access token. >> >> Denis >> >>> The IESG has received a request from the Web Authorization Protocol WG >>> (oauth) to consider the following document: - 'JWT Response for OAuth Token >>> Introspection' >>> <draft-ietf-oauth-jwt-introspection-response-09.txt> as Proposed Standard >>> >>> The IESG plans to make a decision in the next few weeks, and solicits final >>> comments on this action. Please send substantive comments to the >>> >>> last-call@xxxxxxxx >>> mailing lists by 2020-09-04. Exceptionally, comments may >>> be sent to >>> iesg@xxxxxxxx >>> instead. In either case, please retain the beginning >>> of the Subject line to allow automated sorting. >>> >>> Abstract >>> >>> This specification proposes an additional JSON Web Token (JWT) >>> secured response for OAuth 2.0 Token Introspection. >>> >>> The file can be obtained via >>> >>> https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-introspection-response/ >>> >>> >>> >>> No IPR declarations have been submitted directly on this I-D. >>> >>> _______________________________________________ >>> OAuth mailing list >>> >>> OAuth@xxxxxxxx >>> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> >> _______________________________________________ >> OAuth mailing list >> >> OAuth@xxxxxxxx >> https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@xxxxxxxx > https://www.ietf.org/mailman/listinfo/oauth -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
