On Wed, 17 Dec 2014, Jaroslav Imrich wrote: >> given that we already have attrs like "library-manufacturer" >> it may seem weird to have "token", "manufacturer", "model", and >> "serial" instead of "token-label", "token-manufacturer", >> "token-model", and "token-serial". However, we also have "object" and >> "type" instead of "object-label" and "object-type" and I think it's >> good to keep PKCS#11 URIs short and succinct. In other words, I plan >> to add the slot attributes above without changing other names. >> Please let me know if you see any issues with it. >> > >I'll share my latest experience with you. Few days ago I was writing simple >encryption application and I have decided to use PKCS#11 URIs to identify >encryption keys. Then I came to the point where I needed to write down URI >into the config file and I was stuck. I couldn't remember attribute names >even though in past I have implemented .NET library for PKCS#11 URI parsing >and building. Attributes like "token", "type" or "object" seem just >unnatural to me. I don't know maybe it is because I work with PKCS#11 at >programming level but I would never refer to the value of "CKA_LABEL" >attribute with other name than "label". However PKCS#11 URI uses "object" >attribute for object label. Maybe regular non-developer users find current >names suitable and easier to understand/remember but in my ideal world I >would change the attribute names to: Jaroslav, I think that most of the users of the URI may be quite ignorant about the PKCS#11 spec. I don't think they will know about CKA_LABEL attribute, for example. The thing was to come up with some "compromise between how precisely are the URI attribute names mapped to the names in the specification and the ease of use and understanding of the URI scheme", as stated in the ID. I think it's much easier to use and read: pkcs11:object=my-key;token=my-token rather than: pkcs11:object-label=my-key;token-label=my-token where the use of "label" looks quite redundant. Please note that it's about general usability and ease of use of the URI, not how precisely it is mapped to the actual spec. that why we also chose "type" over less understandable "class" which is btw also used in the spec in text: "CK_OBJECT_CLASS is a value that identifies the classes (or types) of objects that Cryptoki recognizes." Jan -- Jan Pechanec <jan.pechanec@xxxxxxxxxx>