Agreed with the security consideration. Just for the record: The life cycle as I understand would include the following.
1. registration (creation) 2. activation 3. de-activation 4. re-activation 5. archival 6. deletion In the above thread, I was talking more about "3. archive". We do not have to have the full life-cycle model here, but it may be a good idea to document why we would not. Nat 2013/2/18 Justin Richer <jric...@mitre.org> > Nat's attack vector presumes lack of logging on the server side, where > doing a "delete" means that you can no longer see anything about who did > what. You could make the same argument if you have a system where users can > register themselves and delete their accounts at will -- someone creates a > fly-by-night account, does bad things, deletes the account. If the site > doesn't have detailed logs in both of these cases, yes, they'll be in the > dark about the bad things that happened when the account/client was active. > It's a valuable security consideration, but I don't think that it's enough > to say that delete is no longer a valid operation. > > I think it's up to the server what "delete" means under the hood, but the > important bit for the protocol is that as far as the client is concerned, > that client_id is dead now. I don't think it's worthwhile to specify it as > a "suspend" operation, because to me "suspend" implies an ability to > "unsuspend", and I really don't think we want to get into the complicated > zombie OAuth client business. But whether on the server side "delete" > translates to "delete everything from the database immediately and burn all > records of it" or instead "set a flag on that client and all of its > outstanding grants so that it can't be used but administrators can still > poke it with a stick" is completely up to the implementation and its > security considerations. > > That said, I think it would make sense to at least describe this potential > problem in the security considerations, and note that the client MUST NOT > use the client_id again. > > -- Justin > > > On 02/17/2013 01:11 AM, Mike Jones wrote: > >> 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<https://www.ietf.org/mailman/listinfo/oauth> >> ______________________________**_________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/**listinfo/oauth<https://www.ietf.org/mailman/listinfo/oauth> >> > > -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
