Open Stack

John,

I think requiring a name for a secret just for UI purposes, unless it would be an index into the secrets database is meaningless.
If a name is provided, my guess is user plans to request it using name (such as in use my-super-master-extra-long-key ).
If no name is provided, the uuid generated as key-id could be duplicated in the name field for UI purposes. Not necessary to even store it in DB, just null is fine there.

Regards
Malini

-----Original Message-----
From: John Wood [mailto:john.wood at RACKSPACE.COM] 
Sent: Tuesday, May 14, 2013 11:38 AM
To: OpenStack Development Mailing List
Subject: [openstack-dev] [barbican] Secret entity constraints

Hello folks,

Just curious what constants we should consider for creating secrets in Barbican.

Currently the only non-nullable attribute on a 'secret' entity is its mime-type, used to specify the format the secret data is formatted in. Should the mime-type have a default value if not specified, say of 'text/plain', or else should clients POSTing new secrets always have to specify the mime-type? Malini also brought up this one: if a default value is desired, should the mime-type be a config file option, or else a tenant/user-specific default value, or a default keyed to the secret type specified?

Multiple secrets can have the same name (or no name currently). After discussion with Jarret, it makes sense to enforce a non-null, non-empty name for a secret, as this could get confusing on a UI display of a tenant's secrets. This name is convenience info about a secret, so it seems duplicate names would be acceptable.  

The expiration date can optionally be specified (null implying the secret never expires). We've previously discussed not returning expired secrets in GET calls. This all seems fine to do, but are there any issues with this approach? 

If the algorithm, bit-length, and/or cypher-type are not specified, then more sophisticated validation will not be possible. Should it be OK for a client to not specify these parameters to save a secret? It seems this should be allowed, with only the mime-type of the secret data verified by Barbican.

Thanks,
John

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev