Hi Dick, some misc feedback below
- 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
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.
(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 &
- 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
- In Section 6.1.8, the text
'Upon receiving the HTTP 401 response when accessing protected
resources per Section 4
(Accessing a Protected Resource)
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
- 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
- Should the reference to Sec 6.3.5 in Sec 6.3.6 instead point at Sec