Re: [GNAP] DID as sub_id or assertion?

[Fabien Imbault <[e-mail]>]

Hi there,

A complementary set of questions for option 1 (SECEVENT):

- are you happy with the current list of subject identifiers? (i.e.
account/email/phone/iss_sub/aliases/opaque)
- what else would you need (in the context of GNAP, please indicate if
important or nice to have)?
- do you agree with having opaque examples in the text?

If needed, you can have a look at
https://tools.ietf.org/html/draft-ietf-secevent-subject-identifiers-07

Thanks.

Fabien

On Wed, Mar 10, 2021 at 6:48 PM Fabien Imbault <[e-mail]>
wrote:

> Thanks for the feedback, although I'm not sure what you mean by too
> abstract.
> Just a quick comment: an assertion in option 2 is not "the fact the
> identifier is resolvable to cryptographic material that *can *be used to
> validate cryptographic assertions". It is merely a statement by the AS that
> "the subject corresponding to the reference has a DID" ("has" is the
> assertion here). Or said otherwise, it is the mapping between as_ref and
> the DID (for that specific case).
>
> On Wed, Mar 10, 2021 at 6:30 PM Tobias Looker <[e-mail]>
> wrote:
>
>> Hi All,
>>
>> Just my two cents, I don't understand why a DID on its own would be
>> regarded as an assertion about the subject. A DID is just an identifier
>> like any other, the fact the identifier is also resolvable to cryptographic
>> material like public keys that *can *be used to validate cryptographic
>> assertions does not make the DID itself an assertion.
>>
>> On first glance of your proposals Fabien I like the simplicity of option
>> 1, option 2 feels too abstracted.
>>
>> Thanks,
>> [image: Mattr website] <https://mattr.global>
>> *Tobias Looker*
>> Mattr
>> [phone]
>> [e-mail]
>> [image: Mattr website] <https://mattr.global> [image: Mattr on LinkedIn]
>> <https://www.linkedin.com/company/mattrglobal> [image: Mattr on Twitter]
>> <https://twitter.com/mattrglobal> [image: Mattr on Github]
>> <https://github.com/mattrglobal>
>> This communication, including any attachments, is confidential. If you
>> are not the intended recipient, you should not read it - please contact me
>> immediately, destroy it, and do not copy or use any part of this
>> communication or disclose anything about it. Thank you. Please note that
>> this communication does not designate an information system for the
>> purposes of the Electronic Transactions Act 2002.
>>
>>
>> On Wed, Mar 10, 2021 at 10:11 PM Fabien Imbault <[e-mail]>
>> wrote:
>>
>>> Hello,
>>>
>>> Notice the question mark in the title. Not to be considered as an
>>> editor's comment.
>>> This thread intends to provide a detailed comment on the
>>> interesting feedback by Kristina: "I would catch up on the thread to
>>> understand why DIDs are thought to be treated as assertions".
>>> In the chat, I answered: "Happy to get the discussion on DIDs. Actually,
>>> could be either or, depending on what we intend to do." Let me expand a bit
>>> on that, to make it understandable (didn't have the time during the
>>> meeting, unfortunately).
>>>
>>> This relates to the items described on slides 20 and 34, which I'll
>>> explain further. I'll highlight as transparently as possible what I think
>>> would be the benefits and downsides of each. Both are probably viable
>>> options, but they correspond to different scopes and objectives. I'll spend
>>> a bit more time on option 2, since it is a different approach compared to
>>> the current draft.
>>>
>>> *1. The first possibility is to use SECEVENT throughout. *
>>> In that case, DIDs should be a part of sub_ids (in the core or in the
>>> extension registry, depending on what Annabelle's WG decides). More
>>> generally, the WG would have to decide which additional sub_ids it needs
>>> (as per Yaron's comment).
>>>
>>> That's obviously the closest to what is described in draft-04. It allows
>>> a communication of subject information between the client and the AS, by
>>> using global identifiers (mail, phone, etc.), or using a local opaque
>>> reference - i.e. governed by the AS (that's probably what we would put in
>>> the examples, unless someone has a better idea - cf issues #16 and #42).
>>>
>>> Assertions relate for instance to the proof of presence of the RO. The
>>> current draft-04 therefore plans for id_tokens and saml2, maybe there could
>>> be other needs later (extension registry).
>>>
>>> - Benefits: identifiers are a key component of GNAP, which makes
>>> integration easier. Possibly one could choose to use DIDs throughout.
>>> - Downsides: email/phone identifiers will probably be used throughout by
>>> most devs (since that's correlation information they have in their user
>>> DB). Which means we should limit what assertions contain, to avoid doing
>>> links between weak global identifiers and hopefully stronger assertions.
>>> That's not really a problem if it's limited to authentication events mostly
>>> (in that perspective, samlv2 could make sense in the core). An assertion is
>>> probably a single value then (not an array).
>>>
>>> Option 1 can be summarized as:
>>>
>>> "subject": {
>>>
>>>    "sub_ids": { }, // request and response (SECEVENT -> including DID
>>> possibly)
>>>
>>>    "assertions": [ ],               // request and response (id_token or
>>> samlv2)
>>>
>>> }
>>>
>>> ("hints" do not exist currently, but are partially covered separately
>>> via "request.user" / the relevance of "principal", discussed in the slide,
>>> is a question mark too - which is a different discussion on end-user != RO).
>>>
>>>
>>>
>>> *2. An alternate possibility is to use SECEVENT only as input/hint*
>>> In that case, DIDs should be a part of assertions (which have a
>>> different meaning compared to option 1).
>>>
>>> The AS only returns an local opaque reference as_ref (while in option 1,
>>> it was only one of many possibilities). Its only job is to help the client
>>> differentiate the response subject. The AS policy might further define the
>>> scope of that reference, as suggested in
>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/210, although
>>> I personally viewed that by default as (2) "as_id" an identifier locally
>>> unique to that AS for all the RSs.
>>>
>>> SECEVENTS are still useful as an input, that's what I presented in
>>> request.hints.self.sub_ids (but it's the responsibility of the AS to match
>>> it with its own reference system - from instance from the email to AS's
>>> local record XUT2MFM1XBIKJKSDU8Q). Note: since the slides, a new
>>> draft-ietf-secevent-subject-identifiers-07 has been published. Notably this
>>> includes an opaque identifier, which the client can use to pass the as_ref
>>> hint to the AS. Thus we wouldn't need any further addition to
>>> SECEVENT, although hints would benefit from further additions (like DIDs
>>> for instance). Notice also that subject_types_supported becomes less
>>> important, because in the worst case scenario, it's simply a hint that
>>> wouldn't be understood and therefore taken into account by the AS.
>>>
>>> The assertions array has a more important role than in option 1 (with
>>> the explicit aim of separating between client hints and validated info
>>> asserted by the AS). It serves as a generic/extendible mapping structure,
>>> e.g. "the AS asserts that opaque reference XUT2MFM1XBIKJKSDU8Q is
>>> matching with these (more or less verifiable) statements." The name
>>> assertion therefore corresponds to the responsibility of the AS in
>>> delivering those statements (cf should/must, issue #49). Some of these
>>> statements relate to identity or auth events (ex: DID, id_token), some
>>> might directly be useful for authorization decisions (like ZKP example in
>>> the parental control example). Possibly some of these validated assertions
>>> could be reused in next interactions.
>>>
>>> Another question that popped-up is the scope of sub_ids. Should they be
>>> about the same user? (I think so). In the case of remote ROs especially, it
>>> might be important that DID be considered as an assertion (about someone
>>> else's) and not as sub_ids, because the AS needs to be careful about who
>>> the client wants to reach (avoid spam, etc.). This is consistent with the
>>> rest of discussion on what to do when end-user != RO, although using
>>> DIDComm might seem a bit early (the paint is very fresh).
>>>
>>> Option 2 was summarized as:
>>>
>>> // (suggestion only, not as an editor)
>>>
>>> "subject": {
>>>
>>>    "as_ref": { // response only (wouldn’t require SECEVENT)
>>>
>>> “as”: “https://ex1.as.com”,
>>>
>>> “ref”: “XUT2MFM1XBIKJKSDU8QM”
>>>
>>>    },
>>>
>>>    "assertions": [ ],               // request and response
>>> (id_token/jwkthumb/DID/VC/etc. -> whatever info can be validated by the AS)
>>>
>>>    "hints": {                       // request only (optional)
>>>
>>>       "self": { // replaces request.user (support SECEVENT here)
>>>
>>>    “sub_ids”: { }, // SECEVENT (including opaque in draft-07 - that
>>> could contain the ref)
>>>
>>>    “assertions”: [ ] // see examples: VC on DOB or ZKP on age (wider
>>> scope, possibly through extensions)
>>>
>>> },
>>>
>>>       "principal": { // new proposal presented at IETF110 (just an idea)
>>>
>>>   “automated”: true, // rule engine
>>>
>>>   “async”: { } // remote ROs
>>>
>>> }
>>>
>>>    }
>>>
>>> }
>>>
>>> - Benefits: as_ref is self supporting (no strong coupling with
>>> SECEVENT), but can still take SECEVENT as an input hint for the AS. It
>>> avoids the risk of making an official association between a weak global
>>> identifier (e.g. email, used elsewhere) and hopefully stronger local
>>> assertions. GNAP would be fully agnostic to whatever identity system is
>>> used, only facilitating interoperability through assertions (second only in
>>> importance compared to the AS opaque reference). Some assertions (possibly
>>> extensions) could also be useful for the AS decision (e.g. VC or ZKP).
>>> - Downsides: opaqueness of as_ref is a feature, not a bug. The opaque
>>> reference is fully managed by the AS, therefore not inherently portable (cf
>>> portability discussions in OIDC currently). There's no explicit binding to
>>> an official identity, only a contextual mapping to AS validated assertions.
>>> It makes it more difficult to match the identifiers from one AS to another
>>> or to correlate with the client user DB (still possible via assertions, if
>>> the AS allows it). Assertions are much more generic (possibly via
>>> extensions), but might require a more advanced mechanism to
>>> request/response only the most relevant information (which makes the AS
>>> policy critical here).
>>>
>>> I hope that clarifies the reasoning for both options. Again I'm not
>>> saying option 2 is better, just saying the trade-offs are different (+
>>> knowing that we need to keep it simple).
>>> - option 1 puts more in sub_ids and less in assertions
>>> - option 2 puts less in the reference and more in assertions
>>> All of this is open to discussion. More generally speaking, on every
>>> part in orange and question mark (?) I would love your ideas and
>>> criticisms. What I intended as an editor is only to highlight where the WG
>>> has important choices to make, before we can make the related PRs.
>>>
>>> A further side comment: IETF EAT RATS was suggested for assertions, but
>>> relates more to the client attestations. It was added as a comment in
>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/44, which is
>>> a distinct topic we'll work on.
>>>
>>> Fabien (editor's hat off)
>>>
>>> --
>>> TXAuth mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/txauth
>>>
>>
>> This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002.
>>
>>