[eventually a wrong one],
as it limits the use of scope in our implementation to the permissions. For
instance, we, for now, left out the "duration scopes" suggested by Eran in his
previous email.
It would be very valuable for us to have more explicit texts regarding the use
of scopes.
Thanks Eran,
Best regards,
Diogo Almeida
On Jul 6, 2010, at 3:03 PM, Eran Hammer-Lahav wrote:
>
>
>
>
> On Jul 3, 2010, at 7:50, Diogo Almeida wrote:
>
>> Good afternoon,
>>
>> I would like to ask the WG two questions regarding -09
>>
&g
Hello David,
Just a small note: if such change was made I believe it would also have to be
reflected on section 4.2 (draft 09), in order to have a coherent scope
parameter.
Best regards,
Diogo Almeida
On Jul 5, 2010, at 5:46 PM, David Recordon wrote:
> Seems like adding, "It'
regarding the
code parameter".
Best regards,
Diogo Almeida
On Jul 3, 2010, at 12:50 PM, Diogo Almeida wrote:
> Good afternoon,
>
> I would like to ask the WG two questions regarding -09
>
> 1)
> On section 3.1, regarding the scope parameter, it reads:
>
> code
> R
Hello,
Both examples in section 2.1 mention a "type" parameter, which, if I'm
interpreting the changes correctly, has been removed in -07.
Assuming it's indeed a typo. Where it reads:
For example (line breaks are for display purposes only):
POST /token HTTP/1.1
Host: server.exampl
en", "expires_in", "scope" and
"state".
Question: Would it make sense to also include an OPTIONAL "refresh_token" to
make this response more in line with section 4.2. Access Token Response. Or the
intention behind the decision of not
guity from the messages / flow without any significant overhead
Best regards,
Diogo Almeida
On Jul 2, 2010, at 5:02 PM, Marius Scurtescu wrote:
> If the scopes granted by the authz server are exactly the ones
> requested by the client then I don't see the need for the authz server
&
;scope" parameter to the values to which the
token grants access.
Furthermore, the authorization server can add any other values deemed
necessary
to determine response scope.
Best regards,
Diogo Almeida
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth