How to name this key-oriented access-protection pattern?

Question

Apparently this key-oriented access-protection pattern:

class SomeKey { 
    friend class Foo;
    SomeKey() {} 
    // possibly non-copyable too
};

class Bar {
public:
    void protectedMethod(SomeKey); // only friends of SomeKey have access
};

... doesn't have a known name yet, thus i'd like to find a good one for it so we can refer to it without breaking our tongues. Suggestions?

It should be:

• succinct
• convey the intent of access-protection
• ideally imply that no proxying is required (?)

Answer 1

I like, in decreasing preference:

• passkey friend idiom
• passkey-door friend idiom
• pass-door friend idiom
• key-door friend idiom
• partial-friend idiom
• restricted-friend idiom

_{I moved away from the key-lock/key-keyhole naming scheme to the pass naming scheme, which grew on me.}

Answer 2

SomeKey looks a bit like a Backstage pass to get into Bar::protectedMethod. So anything in that area should be good: passport idiom, watchword idiom, passkey idiom, VIP idiom..err classy access?

Answer 3

There's other ways to do this, in a more general fashion, using inheritance. Here, class cake functions as both the keyhole and the key. Here, any class that inherits (could also be static inheritance) from cake can access the subset of SomeClass defined to be accessible in cake, and of course, you could have multiple different subsets in multiple different classes.

class cake;
class SomeClass {
    friend class cake;
    void foo();
};
class cake {
    void DoFoo(SomeClass& class) { class.foo(); }
};
class lols : cake {
    // Now we can DoFoo().
};

I'd name it lock and key.

Answer 4

I propose naming this the Badge Idiom, signifying a token presented upon request proving possession of authority. I believe that this is a better metaphor than those revolving around the term Key in many of the other answers here.

'Key' is already fairly overloaded in programming terminology, conflating at least the notions of lookup and of restricted access. Furthermore, real keys usually operate individual locks, not the set of all locks from a manufacturer, and the accepting class in this pattern is a set not of locks but of self-protecting entities being asked to perform actions.

'Badge' conveys the principle that the token grants authority to an entire class of other entities, not just a single object. The term may be too reliant on (US-centric?) police or security imagery, and I did consider terms like Subpoena or Warrant, but they seemed too focused on third party granting of access. Anyway, individuals with a given badge type can compel codified behaviors from the classes of individuals respecting those badges. I see the overall interaction like this:

• A: This party's too loud. Turn down your stereo. (Presents badge)
• B: Oh, OK, officer. (groan)