Am 30.06.2011 18:39, schrieb Eran Hammer-Lahav:
This debate has been going on for 3 years. In OAuth 1.0 it was called
token attributes. Someone just need to write a proposal. Last time I
tried, no one wanted to implement any such mechanism.
we already did
regards,
Torsten.
EHL
*From:*Lodderstedt, Torsten [mailto:t.lodderst...@telekom.de]
*Sent:* Thursday, June 30, 2011 6:38 AM
*To:* Eran Hammer-Lahav; George Fletcher; oauth@ietf.org
*Subject:* AW: [OAUTH-WG] Resource Owner Password Credentials
question/feedback
>Issuing a refresh token is more a function of the access grant
duration than anything else.
Agreed. How shall the user influence this duration? There is no direct
interaction between authz server and end-user.
>The client can always throw away tokens when it is done of if the user
doesn't want to "stay connected", but issuing long term credentials is
not >really something the client asks but the server decides (based on
user approval and policy).
This is a waste of resources. Moreover, how do you explain the
end-user if a long-term authorization shows up in his service
providers account management screen for a certain client he never
explicitly authorized for long-term access?
regards,
Torsten.
*Von:*Eran Hammer-Lahav [mailto:e...@hueniverse.com]
<mailto:[mailto:e...@hueniverse.com]>
*Gesendet:* Donnerstag, 30. Juni 2011 10:48
*An:* Lodderstedt, Torsten; George Fletcher; oauth@ietf.org
<mailto:oauth@ietf.org>
*Betreff:* RE: [OAUTH-WG] Resource Owner Password Credentials
question/feedback
Issuing a refresh token is more a function of the access grant
duration than anything else. The client can always throw away tokens
when it is done of if the user doesn't want to "stay connected", but
issuing long term credentials is not really something the client asks
but the server decides (based on user approval and policy).
EHL
*From:*oauth-boun...@ietf.org <mailto:oauth-boun...@ietf.org>
[mailto:oauth-boun...@ietf.org]
<mailto:[mailto:oauth-boun...@ietf.org]> *On Behalf Of *Lodderstedt,
Torsten
*Sent:* Thursday, June 30, 2011 1:10 AM
*To:* George Fletcher; oauth@ietf.org <mailto:oauth@ietf.org>
*Subject:* Re: [OAUTH-WG] Resource Owner Password Credentials
question/feedback
No exactly the topic but also related to this grant type
There is currently no parameter the client could use to explicitly
request a refresh token. So server-policies based on user, client and
scope are the only mean to decide whether a refresh token is issued or
not. I consider this to limited as there might be the desire this
control this per authorization process, i.e. I client could ask the
user whether he/she wants to "stay connected" or "stay logged in". A
parameter to pass this information to the authz server would be useful.
regards,
Torsten.
*Von:*George Fletcher [mailto:gffle...@aol.com]
<mailto:[mailto:gffle...@aol.com]>
*Gesendet:* Dienstag, 28. Juni 2011 17:47
*An:* oauth@ietf.org <mailto:oauth@ietf.org>
*Betreff:* [OAUTH-WG] Resource Owner Password Credentials
question/feedback
I'm working on spec'ing out a use of the Resource Owner Password
Credentials flow and in trying to map out possible error cases,
realized that there is no good error for the case that the resource
owner's password credentials are invalid. Section 4.3 of draft 16
references section 5.2 for errors. The list of available errors in
section 5.2 are...
error
REQUIRED. A single error code from the following:
invalid_request
The request is missing a required parameter, includes an
unsupported parameter or parameter value, repeats a
parameter, includes multiple credentials, utilizes more
than one mechanism for authenticating the client, or is
otherwise malformed.
invalid_client
Client authentication failed (e.g. unknown client, no
client credentials included, multiple client credentials
included, or unsupported credentials type). The
authorization server MAY return an HTTP 401
(Unauthorized) status code to indicate which HTTP
authentication schemes are supported. If the client
attempted to authenticate via the "Authorization" request
header field, the authorization server MUST respond with
an HTTP 401 (Unauthorized) status code, and include the
"WWW-Authenticate" response header field matching the
authentication scheme used by the client.
invalid_grant
The provided authorization grant is invalid, expired,
revoked, does not match the redirection URI used in the
authorization request, or was issued to another client.
unauthorized_client
The authenticated client is not authorized to use this
authorization grant type.
unsupported_grant_type
The authorization grant type is not supported by the
authorization server.
invalid_scope
The requested scope is invalid, unknown, malformed, or
exceeds the scope granted by the resource owner.
I'm wondering if others have chosen one of these values to represent
the "invalid_credentials" use case.
Thanks,
George
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
