(Working group feedback requested at the end)
Moved here to solicit additional feedback from the group. > 3.1.2.2. Registration Requirements: Comment on last word "path": "Huh? > Scheme, authorization and path is a complete URI minus a query > component. Is the goal to specifically mandate that only the query > component can vary and the rest of the URI MUST be static? If so that should > be stated explicitly rather than implicitly as it is now. But I think, if > that is the > intent, it goes too far. We should also allow for additional path segments to > be added to the URI path beyond the registered prefix. Assuming we can > address the security problem in the next comment." Added after 'path': "(allowing the client to dynamically change only the query component of the redirection URI when requesting authorization)". As for allowing dynamic changes to the path, that's still allowed but not the recommended way. Basically, full registration is best, then dynamic query second best, but anything else is still permitted. > 3.1.2.3. Dynamic Configuration: Comment on "section 6": "The reference to > section 6 is incomplete. Section 6 defines no less than 6 different axis's on > which URI comparisons can vary. Furthermore as recently documented in > draft-thaler-iab-identifier-comparison-00.txt it is trivially easy to screw > up URI > comparisons and the security implications are pretty dire. Personally I think > that the only sane approach given the issues in the previous link is to adopt > section 6.2.1 of RFC 3986. > > I am a bit scared of how to handle partial matches. It's tempting to argue > that > so long as the schema has an authority and at least one path segment then > we can just use a partial string match but boy oh boy do I see people > screwing that one up royally. This is scary enough that I think I can be > argued > into saying that partial pre-registered URIs MUST only differ by the query > component. > > In any case this issues needs to be explicitly called out for all URI > comparisons > required by the spec and normatively defined. Otherwise we will end up > with all the security issues in Dave's ID." Looks like you are contradicting yourself. First you say that limiting to query only is to limited and now you recommend it. It is well established that URI comparison is hard because normalization is hard. That was the main issue in OAuth 1.0. It is also the motivation behind recommending registration of the complete URI. I'm open to requiring string comparison for fully registered URIs but not for dynamic URIs because of the difficulty in applying such a rule to partial registration. Existing text in 3.1.2.3: When a redirection URI is included in an authorization request, the authorization server MUST compare and match the value received against at least one of the registered redirection URIs (or URI components) as defined in [RFC3986] section 6, if any redirection URIs were registered. Suggested addition: If the client registration included the full redirection URI, the authorization server MUST compare the two URIs using simple string comparison as defined in [RFC3986] section 6.2.1. I'm looking for feedback on this proposed addition. EHL
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
