title: Better Understanding of Purpose of Signed Identifiers in Blob Storage (Azure)
body: <p>I am trying to get an understanding of the purpose of signed identifiers when using Shared Access Signatures with Blob storage in Azure.  I know that signed identifiers are basically applied at container level and are a named.  Furthermore, I know that they provide any Shared Access Policies to be valid for longer than an hour (as opposed to when not specifying a signed identifier). I guess my question is couldn't you just apply a shared access signature at the container level with appropriate permissions and expiry time?  Thanks to all that reply.</p>
  
  <hr>
  
  <p>Okay, I think I get now.  So best way to interpret SI's are that they are another level of abstraction for access control at the container level.  Furthermore, they allow you to specify how long policies can be applied before they are revoked.  In both explicit and SI declaration, revocation is pretty much the expiry time.</p>
  
  <p>So my next question is say for instance I have a policy that has been compromised. How exactly do I immediately revoke or change the policy (being that I've defined this policy in my code; how would I change it without having redeploy code)? </p>