Changes between Version 30 and Version 31 of API_security

Timestamp:

08/10/2012 03:11:24 PM (10 months ago)

Author:

jbe

Comment:

--

API_security

@@ -19 +19 @@
 Parameters sent without a value MUST be treated as if they were omitted from the request.  The authorization server MUST ignore unrecognized request parameters.  Request and response parameters MUST NOT be included more than once.
 
-Proposal: When authorizing a client, the user shall see any previously issued long-term authorizations for that client, which are still active. Any previous long-term authorization shall be revoked by default, thus invalidating previously issued refresh tokens for that client, unless the user explicitly agrees to a duplicate authorization (e.g. for multiple native client on different smartphones). For manually registered clients, the behaviour regarding previously issued authorizations may be configured, thus avoiding an interactive decision by the user.
+Proposal: When authorizing a client, the user shall see any previously issued long-term authorizations for that client, which are still active. Any previous long-term authorization shall be revoked by default, thus invalidating previously issued refresh tokens for that client, unless the user explicitly agrees to a duplicate authorization (e.g. for multiple native client on different smartphones). For manually registered clients, the behaviour regarding previously issued authorizations may be configured (field {{{code_grant_multiple}}} in table {{{api_client}}}), thus avoiding an interactive decision by the user.
 
 == Transport layer security ==
@@ -28 +28 @@
 == Client registration ==
 
-Two forms of client registration are supported. System-wide client registration and per-member client registration. Registered clients are stored in the{{{ api_client }}}table of the LiquidFeedback Core. For system-wide clients, the field{{{ member_id }}}is set to NULL, while for member-registered clients, the field{{{ member_id }}}is set to the id of the member, who registered this client for him/herself.
+Two forms of client registration are supported. System-wide client registration and per-member client registration. Registered clients are stored in the {{{api_client}}} table of the LiquidFeedback Core. For system-wide clients, the field {{{member_id}}}is set to NULL, while for member-registered clients, the field {{{member_id}}} is set to the id of the member, who registered this client for him/herself.
 
 Unregistered clients use a client_id identical to their redirection endpoint, when directing the member to the authorization endpoint. The member is then asked automatically if he/she wants to register this client for him/herself.