Use "OpenID Connect" rather than "OIDC"

openid-connect-key-binding-1_0.md

@@ -64,7 +64,7 @@ This specification defines how to bind a public key to an OpenID Connect ID Toke
 
 # Introduction
 
-OpenID Connect (OIDC) enables a Relying Party (RP) to obtain End-User authentication and identity claims from an OpenID Provider (OP) in the form of an ID Token. An RP initiates the protocol by making an authentication request to the OP. The OP authenticates the End-User and returns an ID Token, signed by the OP, containing claims about the End-User.
+OpenID Connect [@!OpenID.Core] enables a Relying Party (RP) to obtain End-User authentication and identity claims from an OpenID Provider (OP) in the form of an ID Token. An RP initiates the protocol by making an authentication request to the OP. The OP authenticates the End-User and returns an ID Token, signed by the OP, containing claims about the End-User.
 
 An RP is often composed of multiple components, such as an RP authenticating component that obtains the ID Token from the OP and an RP consuming component that checks the ID Token presented to it by the authenticating component. To prove it has authenticated an End-User, the authenticating component may present the ID Token to the consuming component as a bearer token. However, bearer tokens are vulnerable to theft and replay attacks: an attacker who obtains the ID Token can impersonate the authenticated End-User.
 
@@ -470,7 +470,7 @@ In a peer-to-peer application, such as video conferencing or messaging, one inst
 
 Consider Alice authenticating to Bob over WebRTC. With a bearer ID Token, an attacker who relays Alice's ID Token to Bob could impersonate Alice. With a key-bound ID Token, Alice signs a value that ties her authenticated identity to the connection, such as the DTLS certificate fingerprint of her media channel, using the key in the `cnf` claim. Bob verifies that signature against the `cnf` claim and is assured both that the OP authenticated Alice and that she controls the channel he is connected to.
 
-The step that is not obvious to an implementer is binding the OIDC identity to the application's own identity or channel: the value signed under the `cnf` key must be something the consuming instance can independently associate with the session, such as a WebRTC certificate fingerprint, a messaging device key, or a per-message signature. How that value is chosen and verified is application-specific and out of scope of this specification.
+The step that is not obvious to an implementer is binding the OpenID Connect identity to the application's own identity or channel: the value signed under the `cnf` key must be something the consuming instance can independently associate with the session, such as a WebRTC certificate fingerprint, a messaging device key, or a per-message signature. How that value is chosen and verified is application-specific and out of scope of this specification.
 
 # Acknowledgements
 
@@ -520,6 +520,10 @@ specification.
 
    [[ To be removed from the final specification ]]
 
+   -02
+
+   * Use official name "OpenID Connect" rather than the unofficial acronym "OIDC".
+
    -01
 
    * Added Use Cases appendix, editorial improvements, clarified DPoP proof typ must be dpop+jwt