Re: [GNAP] Interim Agenda

[Denis <[e-mail]>]

*Important issues still need to be solved and have been left aside. *

A time slot to address the items indicated in this email would be 
appreciated. If not at this session, then at the IETF session.

A short list is below:

*Trust relationships #214*
https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/214

    Three weeks after the opening of this thread, the very first comment
    unfortunately remains true.

    At the moment, there is no text in the draft to describe the
    relationships and/or the trust relationships between the various
    components of the system.

    /*Without a clear definition of these relationships, we might
    continue to argue for ever.*/

The last message was on April 2, 2021

*
*
*User choice and consent, and user notice **#215*
https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/215

    The *User choice and consent*, as well as the *user notice* should
    be made available in the preferred language of the end-user.

    /These two steps which are fundamental from a privacy point of view
    are currently unsupported/missing in the draft./

Still open.

*
*
*Refactoring the internals of access request **#244****
***https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/244

    Denis: Switching the meaning of the words back and forth does not
    allow to progress.

    access token is defined as a data artifact representing a set of
    /*rights*/ and/or /*attributes */attribute is defined as
    characteristics related to a subject.

    It is the time now to define a data structure able to request
    attributes within an access token.

    An RS would be able to tell to a client that if needs one or more
    attributes types (and optionally values) /*and/or*/ some capability
    and /*if the end-user first accepts to request them to a given AS*/
    and if AS is able to provide them, then the access token
    can be generated and is very likely to be accepted by the RS. No
    agreement between them would then be necessary.

Last message was on May 15, 2021

*
**Unlinkability **#241*
https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/241

    Denis: This topic falls under Privacy considerations but has
    consequences on the access token request protocol,
    hence it is opened as a separate thread.

    An end-user identifier present into an access token may be either:

     1. a globally unique identifier (e.g. an email address, a social
        security number), or
     2. an identifier locally unique to that AS for all the RSs, or
     3. an identifier unique for every AS - RS pair, or
     4. a temporary identifier for a single access (i.e. a large random
        identifier).

    Justin: Since access tokens are opaque to clients, clients do not
    have any input into the contents of the access token itself,
                  including any inclusion or format of user identifiers.

*Closed* by Justin on April 21 , 2021


*How can an AS determine "what is needed" to fulfill the request ? 
**#264****
***https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/264

    Denis : In section 1.4, the text states:

    ( 3) The AS processes the request and determines what is needed to
    fulfill the request.

    How can the AS "*/determine what is needed to fulfill the request/*" ?

    Shall the AS have established some prior relationship ?

    If yes, what such relationships consist of ?
    If no, can "other means" be used ?

Up to now, there is no response from anyone.


*What kind of control may a client have about the content of a returned 
access token ? **#265*
https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/265

This issue has been opened on a Saturday and closed immediately the day 
after on a Sunday by Justin.

It is questionable whether it is fair to close an issue during a 
week-end without allowing even _a single working day_
for other people to comment or respond.

This issue has been *closed in less than 24 hours*, without any 
intermediary status like "*Pending Closed*".

IMO, such a practice should be changed.

Since then, you may have noticed that discussions with WG members are 
not taking place any more, except between the three editors.


*The access token verifications to be performed by the RS should be 
described **#30****
***https://github.com/ietf-wg-gnap/gnap-resource-servers/issues/30

    Denis: A key issue is whether the GNAP core is a *framework* or is
    able to define *at least one interoperable protocol*.

    The main reason of the existence of the IETF is to define
    *interoperable protocols*

*Closed* by Justin on June 5 , 2021


Denis


> The agenda, slides and a Meetecho link are available at 
> https://datatracker.ietf.org/meeting/interim-2021-gnap-04/session/gnap 
> <https://datatracker.ietf.org/meeting/interim-2021-gnap-04/session/gnap>
>
> See you there!
>
>                 Yaron
> *From: *TXAuth <[e-mail]> on behalf of Justin Richer 
> <[e-mail]>
> *Date: *Monday, June 14, 2021 at 21:58
> *To: *GNAP Mailing List <[e-mail]>
> *Subject: *[GNAP] Interim Agenda
> Hi everyone,
> As a reminder, we’ve got an interim meeting tomorrow afternoon. The 
> editors are planning on the following agenda for discussion:
>
>   * Core draft update
>
>   * Mix-up attack
>
>   * Signature methods
>
>   * What topics to focus on before IETF 111
>
> — Justin
>
> -- TXAuth mailing list [e-mail] 
> https://www.ietf.org/mailman/listinfo/txauth
>