@misc{rfc4768,
    series =    {Request for Comments},
    number =    4768,
    howpublished =  {RFC 4768},
    publisher = {RFC Editor},
    doi =       {10.17487/RFC4768},
    url =       {https://www.rfc-editor.org/info/rfc4768},
    author =    {Sam Hartman},
    title =     {{Desired Enhancements to Generic Security Services Application Program Interface (GSS-API) Version 3 Naming}},
    pagetotal = 12,
    year =      2006,
    month =     dec,
    abstract =  {The Generic Security Services API (GSS-API) provides a naming architecture that supports name-based authorization. GSS-API authenticates two named parties to each other. Names can be stored on access control lists (ACLs) to make authorization decisions. Advances in security mechanisms and the way implementers wish to use GSS-API require this model to be extended for the next version of GSS-API. As people move within an organization or change their names, the name authenticated by GSS-API may change. Using some sort of constant identifier would make ACLs more stable. Some mechanisms, such as public-key mechanisms, do not have a single name to be used across all environments. Other mechanisms, such as Kerberos, may include group membership or role information as part of authentication. This document motivates extensions to GSS-API naming and describes the extensions under discussion. This memo provides information for the Internet community.},
}