Groups keyboard shortcuts have been updated
Dismiss
See shortcuts
Misc feedback on draft-hardt-oauth-01
3 views
Skip to first unread message
Paul Madsen
Feb 8, 2010, 4:00:35 PM2/8/10
to oauth-...@googlegroups.com
Hi Dick, some misc feedback below
paul
------------------------------------------
- in Section 1.2 , Given the association of 'assertion' (SAML or otherwise) with user SSO, perhaps a note to distinguish this application of assertions from that 'norm'? ie this assertion reflects the client identity, and not that of a user...
- in Section 1.2, suggest
When the Protected Resource is presented with an expired Access Token by the Client, the Protected Resource returns an error. The Client presents the assertion or **account name and password** once again to the Authorization Server to obtain a new Access Token.
- Figure 2 used is in the context of the user-delegation profiles, but no user is shown. This in contrast to the web delegation profile shown in Figure 4 (where admittedly the browser gives you an opening)
- Figure 3 is used in the context of the username/password delegation profile. From the text, the impression might be that the token refresh is specific to this profile, and not relevant, for example, to the web app profile
I acknowledge that the intro text for the Delegation profiles is more general. But moving the refresh sequence diagram after the web delegation sequence diagram would clarify the relationship
- For consistency with Figures 2, Figure 4 should show the Client making a call to the Protected Resource using the access token, i.e. steps (D) & (E)
- In Section 3 'Definitions', markup error in 'Client Identifier'
Similar for 'Refresh Token'
- For the definition of Refresh token, suggest
a long lived bearer token used by a Client to acquire an Access Token from an Authorization Server **that issued the Refresh Token**
- What is the difference between a 'client secret' and a password used by a client to authenticate to the AS in the autonomous user name & pwd profile?
- Text in Sections 6.1.8, 6.2.8 and 6.3.7 is the same. Why duplicate instead of simply referencing Section 6.1.8 from those that follow? Or pull the relevant refresh sections out as generic to the delegation profiles?
- In Section 6.1.8, the text
'Upon receiving the HTTP 401 response when accessing protected resources per Section 4 (Accessing a Protected Resource), the Client makes an HTTPS request to the Authorization Server's Refresh Token URL using POST'
appears to preclude the Client refreshing the access token _before_ it has expired?
- Section 5.1 has intro text that warns against the profile being used for clients acting on behalf of a user. Does Section 5.2 need the same text?
- Should the reference to Sec 6.3.5 in Sec 6.3.6 instead point at Sec 6.2.6?
paul
------------------------------------------
- in Section 1.2 , Given the association of 'assertion' (SAML or otherwise) with user SSO, perhaps a note to distinguish this application of assertions from that 'norm'? ie this assertion reflects the client identity, and not that of a user...
- in Section 1.2, suggest
When the Protected Resource is presented with an expired Access Token by the Client, the Protected Resource returns an error. The Client presents the assertion or **account name and password** once again to the Authorization Server to obtain a new Access Token.
- Figure 2 used is in the context of the user-delegation profiles, but no user is shown. This in contrast to the web delegation profile shown in Figure 4 (where admittedly the browser gives you an opening)
- Figure 3 is used in the context of the username/password delegation profile. From the text, the impression might be that the token refresh is specific to this profile, and not relevant, for example, to the web app profile
I acknowledge that the intro text for the Delegation profiles is more general. But moving the refresh sequence diagram after the web delegation sequence diagram would clarify the relationship
- For consistency with Figures 2, Figure 4 should show the Client making a call to the Protected Resource using the access token, i.e. steps (D) & (E)
- In Section 3 'Definitions', markup error in 'Client Identifier'
Similar for 'Refresh Token'
- For the definition of Refresh token, suggest
a long lived bearer token used by a Client to acquire an Access Token from an Authorization Server **that issued the Refresh Token**
- What is the difference between a 'client secret' and a password used by a client to authenticate to the AS in the autonomous user name & pwd profile?
- Text in Sections 6.1.8, 6.2.8 and 6.3.7 is the same. Why duplicate instead of simply referencing Section 6.1.8 from those that follow? Or pull the relevant refresh sections out as generic to the delegation profiles?
- In Section 6.1.8, the text
'Upon receiving the HTTP 401 response when accessing protected resources per Section 4 (Accessing a Protected Resource), the Client makes an HTTPS request to the Authorization Server's Refresh Token URL using POST'
appears to preclude the Client refreshing the access token _before_ it has expired?
- Section 5.1 has intro text that warns against the profile being used for clients acting on behalf of a user. Does Section 5.2 need the same text?
- Should the reference to Sec 6.3.5 in Sec 6.3.6 instead point at Sec 6.2.6?
Dick Hardt
Feb 8, 2010, 5:08:32 PM2/8/10
to oauth-...@googlegroups.com
Thanks for the feedback Paul!
fyi: I'm going to see how things evolve on the IETF list before making edits.
-- Dick
--
You received this message because you are subscribed to the Google Groups "OAuth WRAP WG" group.
To post to this group, send email to oauth-...@googlegroups.com.
To unsubscribe from this group, send email to oauth-wrap-w...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/oauth-wrap-wg?hl=en.
Reply all
Reply to author
Forward
0 new messages