Draft: draft-ietf-gnap-core-protocol

Commentary: Splits user code into two methods , with no URI in the response and with a dynamic URI in the response . 
 Deploy Preview for gnap - core - protocol - editors - draft ready ! Explore the source changes : Inspect the deploy log : Browse the preview : 
 Seems fine , interesting PR 
 In the section “ Display of a Short User Code ” it says the URL MUST be stable so that the client can be statically configured with it . This seems to contradict the idea of returning the URL in the response here especially since the URL is n’t even required . Either the client is statically configured with a URL and so it does n’t need the URL in the response , or the client needs the URL in the response because it is not statically configured . It seems the MUST is too restrictive here . 
 The normative language might need to be tweaked here , but some background could help : This is based off of similar requirements in as this takes the place of the . Note that the equivalent of is just to use the interaction method , which allows us to avoid the security issues enumerated in that RFC around that function . 
 Proposal change set : create a three - tier interaction start method to handle different use cases with different dynamic portions : long arbitrary URL , suitable for QR code or browser redirect short arbitrary URL plus user code , suitable for things like set - top boxes that ca n't rely on QR codes on secondary devices and ca n't redirect user code alone , no URL included in the response ; URL the user is sent to is static ; suitable for limited interaction devices like voice - only interfaces that ca n't show a different URL at runtime This would probably change the name of the start mode , remove the from the start mode , and create a new kind of start mode that has both dynamic URL and user code in the response . 
 Yaron : it is unclear to me what the goal of the user - code interaction is , in other words what is the threat model . If it 's just " second factor , something you have " , then an OTP MFA device would be simpler and offer the same security .  : This is an equivalent function of the OAuth Device Flow : It ’s not about a second factor for authenticating the user , really , it ’s about facilitating authorization on a secondary device through the use of a user - typed code to tie the back end and front end together .   : Ok - several others have been asking as well . I wrote up this page basically there are assertions from the programmer of the app , and from the app itself that are passed in the i d token ( whatever ) from the user device . Note that this means that not all assertions are signed by the same key in this case ! Nor are all the attributes about the subject . Some are just in support of the level of assurance . The big difference with FIDO U2F and II is that the keys are bound to the user in the device , not in the RP . 
 The issue is about the provenance of the user assertions . Or - how can the recipient know that code faithfully represents the user for both intent and presence . In other words , if the provenance of the 2nd factor is in doubt , why should it be trusted . I would point out the web authN addresses this issue and well as payment request in W3C. n.b . The user gestures , hello , bio , whatever would fall into this same category . 
 The user code is an OTP issued by the AS to identify the client 's request , not to identify the user . It 's assumed that the user will authenticate at the AS on top of presenting the user code . That user authentication could use MFA of some type , entirely separate from the user code , which is where webauthn and FIDO would come into play . The precedent for this feature is the OAuth device flow where the user uses a separate device to interact with the AS and authorize the client . The device flow , like OAuth itself , does n't say anything about how the user authenticates . 
 OK , that is your model . In my model all of the IAL2 and AAL2 claims get bundled up into a single packet and sent to the AS and GC . I know that GNAP does n't claim to be OIDC , but it should at least co - exist with it . 
 " GNAP does n't claim to be OIDC , but it should at least co - exist with it . " yes indeed , but that does n't mean we need to bundle everything at the core of GNAP . We can also integrate with whatever identity layer is chosen ( OIDC , SSI , etc ) as extension points . As a first step it would be useful to make a complete example of GNAP + OIDC working together . As for the clarification requested in this thread , the separation of concerns makes it clearer I think . The user code is n't MFA . 
 Need to explain in the user code section ( or sections ) that the code is n't MFA for the user , it 's meant to associate the user 's session with the pending grant request . See also proposed changes in
Paragraph (version A):
If the client instance is capable of displaying or otherwise
communicating a short, human-entered code to the RO, the client
instance indicates this by including "user_code" in the array under
the "start" key.  This code is to be entered at a static URI that
does not change at runtime.  While this URI is generally hosted at
the AS, the client instance can make no assumptions about its
contents, composition, or relationship to the AS grant URI.
Paragraph (version B):
If the client instance is capable of displaying or otherwise
communicating a short, human-entered code to the RO, the client
instance indicates this by including "user_code" in the array under
the "start" key.  This code is to be entered at a static URI that
does not change at runtime.  The client instance has no reasonable
means to communicate a dynamic URI to the RO, and so this URI is
usually communicated out of band to the RO through documentation or
other messaging outside of GNAP.  While this URI is generally hosted
at the AS, the client instance can make no assumptions about its
contents, composition, or relationship to the AS grant URI.
Paragraph (version B):
If this interaction mode is supported for this client instance and
request, the AS returns a user code as specified in response-
interact-usercode.  The client instance manages this interaction
method as described in interaction-usercode.
Paragraph (version B):
If the client instance is capable of displaying or otherwise
communicating a short, human-entered code along with a short, human-
entered URI to the RO, the client instance indicates this by
including "user_code_uri" in the array under the "start" key.  This
code is to be entered at the dynamic URL given in the response.
While this URL is generally hosted at the AS, the client instance can
make no assumptions about its contents, composition, or relationship
to the AS grant URL.
Paragraph (version B):
If this interaction mode is supported for this client instance and
request, the AS returns a user code and interaction URL as specified
in response-interact-usercodeuri.  The client instance manages this
interaction method as described in interaction-usercodeuri.
Paragraph (version A):
The client instance MUST communicate the "code" to the end user in
some fashion, such as displaying it on a screen or reading it out
audibly.
Paragraph (version A):
The client instance SHOULD also communicate the URI if possible to
facilitate user interaction, but since the URI should be stable, the
client instance should be able to safely decide to not display this
value.  As this interaction mode is designed to facilitate
interaction via a secondary device, it is not expected that the
client instance redirect the end user to the URI given here at
runtime.  Consequently, the URI needs to be stable enough that a
client instance could be statically configured with it, perhaps
referring the end user to the URI via documentation instead of
through an interactive means.  If the client instance is capable of
communicating an arbitrary URI to the end user, such as through a
scannable code, the client instance can use the request-interact-
redirect mode for this purpose instead of or in addition to the user
code mode.
Paragraph (version B):
The URI that the end user is intended to enter the code into MUST be
stable, since the client instance is expected to have no means of
communicating a dynamic URI to the end user at runtime.
Paragraph (version B):
As this interaction mode is designed to facilitate interaction via a
secondary device, it is not expected that the client instance
redirect the end user to the URL given here at runtime.  If the
client instance is capable of communicating an short arbitrary URI to
the end user for use with the user code, the client instance can
instead use the request-interact-usercodeuri method instead.  If the
client instance is capable of communicating a long arbitrary URI to
the end user, such as through a scannable code, the client instance
can use the request-interact-redirect mode for this purpose instead
of or in addition to the user code mode.
Paragraph (version B):
See details of the interaction in interaction-usercode.
Paragraph (version B):
If the client instance indicates that it can request-interact-
usercode and the AS supports this mode for the client instance's
request, the AS responds with a "user_code" field.  This field is an
object that contains the following members.
Paragraph (version B):
The client instance MUST also communicate the URI to the end user.
Since it is expected that the end user will continue interaction on a
secondary device, the URI needs to be short enough to allow the end
user to type or copy it to a secondary device without mistakes.
Paragraph (version A):
In many cases, the URI indicates a web page hosted at the AS,
allowing the AS to authenticate the end user as the RO and
interactively provide consent.  If the URI is hosted by the AS, the
AS MUST determine the grant request being referenced from the URI
value itself.  If the URI cannot be associated with a currently
active request, the AS MUST display an error to the RO and MUST NOT
attempt to redirect the RO back to any client instance even if a
request-interact-callback-redirect.  If the URI is not hosted by the
AS directly, the means of communication between the AS and this URI
are out of scope for this specification.
Paragraph (version B):
In many cases, the URI indicates a web page hosted at the AS,
allowing the AS to authenticate the end user as the RO and
interactively provide consent.  The URI value is used to identify the
grant request being authorized.  If the URI cannot be associated with
a currently active request, the AS MUST display an error to the RO
and MUST NOT attempt to redirect the RO back to any client instance
even if a request-interact-callback-redirect.  If the URI is not
hosted by the AS directly, the means of communication between the AS
and this URI are out of scope for this specification.
Paragraph (version A):
When the end user is directed to enter a short code through the
response-interact-usercode mode, the client instance communicates the
user code to the end user and directs the end user to enter that code
at an associated URI.  This mode is used when the client instance is
not able to facilitate launching an arbitrary URI.  The associated
URI could be statically configured with the client instance or
communicated in the response from the AS, but the client instance
communicates that URI to the end user.  As a consequence, these URIs
SHOULD be short.
Paragraph (version A):
In many cases, the URI indicates a web page hosted at the AS,
allowing the AS to authenticate the end user as the RO and
interactively provide consent.  If the URI is hosted by the AS, the
AS MUST determine the grant request being referenced from the user
code.  If the user code cannot be associated with a currently active
request, the AS MUST display an error to the RO and MUST NOT attempt
to redirect the RO back to any client instance even if a request-
interact-callback-redirect.  If the interaction component at the user
code URI is not hosted by the AS directly, the means of communication
between the AS and this URI, including communication of the user code
itself, are out of scope for this specification.
Paragraph (version B):
When the end user is directed to enter a short code through the
response-interact-usercode mode, the client instance communicates the
user code to the end user and directs the end user to enter that code
at an associated URI.  This mode is used when the client instance is
not able to communicate or facilitate launching an arbitrary URI.
The associated URI could be statically configured with the client
instance or in the client software's documentation.  As a
consequence, these URIs SHOULD be short.  The user code URI MUST be
reachable from the end user's browser, though the URI is usually be
opened on a separate device from the client instance itself.  Since
it is designed to be typed in, the URI SHOULD be accessible from an
HTTP GET request and MUST be protected by HTTPS or equivalent means.
Paragraph (version A):
The client instance MUST NOT modify the URI when launching it, in
particular the client instance MUST NOT add any parameters to the
URI.  The user code URI MUST be reachable from the end user's
browser, though the URI is usually be opened on a separate device
from the client instance itself.  The URI MUST be accessible from an
HTTP GET request and MUST be protected by HTTPS or equivalent means.
Paragraph (version B):
When the end user is directed to enter a short code through the
response-interact-usercodeuri mode, the client instance communicates
the user code and associated URI to the end user and directs the end
user to enter that code at the URI.  This mode is used when the
client instance is not able to facilitate launching an arbitrary URI
but can communicate arbitrary values like URIs.  As a consequence,
these URIs SHOULD be short.  The client instance MUST NOT modify the
URI when communicating it to the end user; in particular the client
instance MUST NOT add any parameters to the URI.  The user code URI
MUST be reachable from the end user's browser, though the URI is
usually be opened on a separate device from the client instance
itself.  Since it is designed to be typed in, the URI SHOULD be
accessible from an HTTP GET request and MUST be protected by HTTPS or
equivalent means.
Paragraph (version B):
When the RO enters this code at the given URI, the AS MUST uniquely
identify the pending request that the code was associated with.  If
the AS does not recognize the entered code, the interaction component
MUST display an error to the user.  If the AS detects too many
unrecognized code enter attempts, the interaction component SHOULD
display an error to the user and MAY take additional actions such as
slowing down the input interactions.  The user should be warned as
such an error state is approached, if possible.