Draft: draft-ietf-gnap-core-protocol

Commentary: Adds the field for requesting information for a specific user , separate from identifying the current end - user . Also adds a security considerations section addressing asynchronous authorization methods . 
 To edit notification comments on pull requests , go to your . 
 Normally we think about releasing subject information being about the current end - user , but that 's not necessarily universal . The use case from CIBA :  is a support engineer with a company  is a customer of that company  calls the company and talks to   needs to authenticate , from her system , that  is the person tied to the account in question  's client messages the AS to request  's information ( probably including an identifier for  in the request ) The AS reaches out to  to approve Alice 's client to get  's information  approves  's request ( probably on a pre - enrolled device ) The AS sends  's information back to  's client Note a few key assumptions with this : At no point does Alice 's client think that  is logging in .  and  both need accounts of some type at the AS  's account ( or client ) need the rights to request someone else 's    approval mechanism needs to be tied to his account ahead of time ( since  is n't running the client and the AS needs to reach out to him out of band )  's approval needs to be clearly directed to tell  that it 's  ( and alice 's client ) asking for his info  might need to log in / interact with the AS as part of this , or it might be tied to the client instance ( maybe  has logged in for the day and that association is remembered by the AS ? ) 
 This is an interesting use case . Yet CIBA does n't necessarily require an AS to work , as long as one is only interested in getting scopes . Is there a generic use case for cross - user subject information + required AS ? Or maybe we should explain the value of the AS in that specific case ? 
 We will add an example in section D that shows how this would work and verify that the language around subject identifiers is sufficiently robust to encapsulate this . This might also add additional security and privacy considerations when used in this mode because multiple people are now involved explicitly . 
 I think this could be marked as NEEDS TEXT ? 
 I think it mostly just needs to be as an example , and I can do that . 
 Fine ;-) ( on my side , I always tend to consider CIBA as some degenerate phishing experiment , but maybe that 's too extreme )
Paragraph (version B):
In this scenario, the end user and resource owner are two different
people.  In this scenario, the client instance already knows who the
end user is, likely through a separate authentication process.  The
end user, operating the client instance, needs to get subject
information about another person in the system, the RO.  The RO is
given an opportunity to release this information using an
asynchronous interaction method with the AS.  This scenario would
apply, for instance, when the end user is an agent in a call-center
and the resource owner is a customer authorizing the call center
agent to access their account on their behalf.
Paragraph (version B):
Precondition: The end user is authenticated to the client instance,
and the client instance has an identifier representing the end user
that it can present to the AS.  This identifier should be unique to
the particular session with the client instance and the AS.
Paragraph (version B):
The RO communicates a human-readable identifier to the end user,
such as an email address or account number.  This communication
happens out of band from the protocol, such as over the phone
between parties.  Note that the RO is not interacting with the
client instance.
Paragraph (version B):
The end user communicates the identifier to the client instance.
The means by which the identifier is communicated to the client
instance is out of scope for this specification.
Paragraph (version B):
The client instance request.  The request includes the RO's
identifier in the request-subject "sub_ids" field, and the end
user's identifier in the request-user of the request.  The request
includes no interaction start methods, since the end user is not
expected to be the one interacting with the AS.  The request does
include the request-interact-callback-push to allow the AS to
signal to the client instance when the interaction with the RO has
concluded.
Paragraph (version B):
The AS sees that the identifier for the end user and subject being
requested are different.  The AS determines that it can reach out
to the RO asynchronously for approval.  While it is doing so, the
AS returns a response-continue with a "finish" nonce to allow the
client instance to keep polling after interaction with the RO has
concluded.
Paragraph (version B):
The AS contacts the RO and has them authenticate to the system.
The means for doing this are outside the scope of this
specification, but the identity of the RO is known from the
subject identifier sent in (3).
Paragraph (version B):
The RO is prompted to authorize the end user's request via the
client instance.  Since the end user was identified in (3) via the
user field, the AS can show this information to the RO during the
authorization request.
Paragraph (version B):
The RO pushes the interaction-pushback to the client instance.
Note that in the case the RO cannot be reached or the RO denies
the request, the AS still sends the interaction finish message to
the client instance, after which the client instance can negotiate
next steps if possible.
Paragraph (version B):
The client instance validates the interaction finish message and
continue-after-interaction.
Paragraph (version B):
The AS returns the RO's response-subject to the client instance.
Paragraph (version B):
The client instance can display or otherwise utilize the RO's user
information in its session with the end user.  Note that since the
client instance requested different sets of user information in
(3), the client instance does not conflate the end user with the
RO.
Paragraph (version B):
GNAP allows the RO to be contacted by the AS asynchronously, outside
the regular flow of the protocol.  This allows for some advanced use
cases, such as cross-user authentication or information release, but
such advanced use cases have some distinct issues that implementors
need to be fully aware of before using these features.
Paragraph (version B):
First, in many applications, the return of a subject information to
the client instance could indicate to the client instance that the
end-user is the party represented by that information, functionally
allowing the end-user to authenticate to the client application.
While the details of a fully functional authentication protocol are
outside the scope of GNAP, it is a common exercise for a client
instance to be requesting information about the end user.  This is
facilitated by the several interaction-start defined in GNAP that
allow the end user to begin interaction directly with the AS.
However, when the subject of the information is intentionally not the
end-user, the client application will need some way to differentiate
between requests for authentication of the end user and requests for
information about a different user.  Confusing these states could
lead to an attacker having their account associated with a privileged
user.  Client instances can mitigate this by having distinct code
paths for primary end user authentication and requesting subject
information about secondary users, such as in a call center.  In such
use cases, the client software used by the resource owner (the
caller) and the end-user (the agent) are generally distinct, allowing
the AS to differentiate between the agent's corporate device making
the request and the caller's personal device approving the request.
Paragraph (version B):
Second, RO's interacting asynchronously do not usually have the same
context as an end user in an application attempting to perform the
task needing authorization.  As such, the asynchronous requests for
authorization coming to the RO from the AS might have very little to
do with what the RO is doing at the time.  This situation can
consequently lead to authorization fatigue on the part of the RO,
where any incoming authorization request is quickly approved and
dispatched without the RO making a proper verification of the
request.  An attacker can exploit this fatigue and get the RO to
authorize the attacker's system for access.  To mitigate this, AS
systems deploying asynchronous authorization should only prompt the
RO when the RO is expecting such a request, and significant user
experience engineering efforts need to be employed to ensure the RO
can clearly make the appropriate security decision.  Furthermore,
audit capability, and the ability to undo access decisions that may
be ongoing, is particularly important in the asynchronous case.