At the oauth session at IETF 80, I volunteered to review the use
cases document (draft-zeltsan-oauth-use-cases).

Overall I liked the document a lot and thought the structure (pre-
conditions, post-conditions, requirements) was excellent.  I do
wonder if the post-conditions aren't somewhat overly focused on
process rather than state in many cases ("Alice's browser downloads
a script [ ... ]"), but that may be a terminological question around
"post-conditions" rather than much to do with actual content.

I also think that it may help to identify which requirements are
in-scope for the working group and which are not.  For example,
in 3.11 "The server at www.social.example.com must be able to
redirect Alice's browser to www.sipservice.example.com" is clearly
out-of-scope for oauth, but "The application running at
www.sipservice.example.com must be capable of authenticating Alice
and obtaining her authorization of a request from www.social.example.com"
is not, or at least both the authn and authz steps may not be, and
that would benefit from clarification.  And come
to think of it, that's a pretty good example of a case where the
distinction between "pre-condition" and requirement isn't all that
clear.

Individual sections:

3.1  I thought the discussion of token lifetime was a bit muddled.
I think it's probably sufficient to say that expired tokens may be
reissued and that it is possible, when appropriate, to issue relatively
long-lived tokens.

3.2  I didn't understand the second bullet item under "pre-conditions."
I tried substituting both "not" and "now" for "no" and neither of them
worked all that well.

3.11 I think "The application at www.social.example.com must be able to
translate the messages of the Alice's VoIP applet into SIP and RTP
messages" is almost certainly irrelevant.

3.12 I'm insufficiently familiar with XRD to know if it protects private
patient data sufficiently to satisfy HIPPA and other legal requirements.
The discovery component of this seems dicey and can probably be
addressed in a less touchy scenario.

If this document is to provide guidance during the development of
protocol documents, I'm not sure it's worth the effort to sort out pre-
conditions and requirements, although I do think I'd try to put some
effort into identifying what's going to be done by the working group and
what's not.

Overall I think it's an extremely useful document.

Melinda
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Reply via email to