I agree. If we have it at all, DELETE should be a declaration by the Client
that requests by it should no longer be honored. It should be up to the Server
whether to implement this as suspension or deletion. At most, I believe it
should be an optional operation, which MAY be supported.
-- Mike
-----Original Message-----
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Nat
Sakimura
Sent: Saturday, February 16, 2013 10:04 PM
To: John Bradley
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Registration: RESTful client lifecycle management
> When sending an update, a client MUST send all metadata fields
> returned from the server in its initial registration or previous read
> or update call, including its client_id. A server MAY replace any
> missing or invalid fields with default values, or it MAY return an
> error as described in the Error Response section. A server MUST return
> all provisioned fields in its response. A server MUST NOT change the
> client_id field. A server MAY change the client_secret and/or
> refresh_access_token fields.
Say the client registered some value. Sometime later, the server changed a
value due to some policy or security reasons etc. The client when UPDATES with
the previously registered value, what is going to happen to the changed value?
>> DELETE to be used correctly is I think going to delete the client_id and all
>> associated tokens and cause a ripple effect in removing grants associated
>> with that client_id.
>
> This is how I would interpret it as well. It's de-provisioning the
> client, not resetting it.
For DELETE, I can think of an attack such that
1. Register as a client.
2. Send spam links to random users.
3. When user "authorizes", suck the user data such as contacts out.
4. DELETE the registration and disappear.
To prevent something like this, it should probably be something more akin to
"suspend" rather than completely de-provisioning.
_______________________________________________
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
