Subject: [OAUTH-WG] Use cases document review

From: Melinda Shore <[email-masked]>
Date: Tue, 19 Apr 2011 15:29:27 -0800

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

---

From: "Zeltsan, Zachary (Zachary)" <[email-masked]>
Date: Thu, 21 Apr 2011 03:35:50 -0500

Melinda,

Thank you for the review and feedback.

We (the co-authors) have also received comments on the draft from Thomas (copied). 
I plan to address all comments and respond by the end of the next week.

Zachary

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Melinda Shore
Sent: Tuesday, April 19, 2011 7:29 PM
To: [email-masked]
Subject: [OAUTH-WG] Use cases document review

Individual sections:

Melinda
_______________________________________________
OAuth mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/oauth

---

From: "Zeltsan, Zachary (Zachary)" <[email-masked]>
Date: Fri, 29 Apr 2011 17:09:07 -0500

Melinda,

My comments are inline.

With thanks,

Zachary
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Melinda Shore
Sent: Tuesday, April 19, 2011 7:29 PM
To: [email-masked]
Subject: [OAUTH-WG] Use cases document review

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 [ ... ]"),
[z.z] I understand your observation regarding the post-conditions. In all use cases (if everything went right) a client receives an access token at the end. The intention was to provide in post-conditions the additional use-case-specific details.

...but that may be a terminological question around "post-conditions" rather than much to do with actual content.
[z.z] I agree.

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.
[z.z]  www.social.example.com plays a role of OAuth client implemented on a web server in this use case. If such a client cannot redirect the user's browser, it cannot participate in the OAuth procedure as intended in this use case. The requirement is necessary for the described case.
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.
[z.z] I agree that this particular requirement could be re-formulated as a pre-condition (e.g., "The server at www.social.example.com is able to redirect Alice's browser to www.sipservice.example.com<http://www.sipservice.example.com> " ). But, I think, that the requirement is more relevant to the process than to the situation existed before the start of the process.
I am open to the proposals for clarification.
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.
[z.z] The word "reissued" could be misunderstood. After an access token expired it is not reissued. A new token can be obtained as a result of a (repeated) OAuth procedure.
Also, it was important to emphasize that a long-lived token (i.e., refresh token) is not used for access to the user resource, but for exchange for a new access token.

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.
[z.z] This item is intended to provide justification for the use case: the gaming application itself has to update information on the user's social site, because there is no a web server that supports this application, supports oauth, and so, it can make the update.
Would the following modification clarify?
"There is no a web site supporting this application and capable of handling the OAuth flow "--> "The gaming application does not have a supporting web site that is capable of accessing Alice's database at www.fun.example.com<http://www.fun.example.com>"

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.
[z.z] I agree that it is not relevant to OAuth, but the requirement is necessary for the use case.

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.
[z.z] XRD (mentioned as an example) is a mechanism used for discovering Alice's personal health data store. It does not handle the user data stored at ww.pcp.example.com<http://www.pcp.example.com> . Perhaps George, who has contributed this use case, may have additional comments.

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.

[z.z] The draft documents the use cases that have been discussed on the list (at least some of them). I believe it helps to understand the specification. The requirements, in my opinion, are useful for determining whether a use case is supported.

Melinda