Re: [Txauth] (no subject)

[Kathleen Moriarty <[e-mail]>]

Hey Dick,

Thanks for your questions and all of your hard work.  I'll respond inline
as not to miss anything.

On Wed, Jul 29, 2020 at 1:07 PM Dick Hardt <[e-mail]> wrote:

> Hey Kathleen
>
> A couple questions on your presentation:
>
> 1) Which versions of the documents did you review?
>
Your last posted version to the datatracker.
I had started with the latest in the datatracker for Justin, but switched
when he announced the update.  Although my skim on the datatracker one had
similar impressions in terms of structure, ease of use, etc.


>
> 2) Would you elaborate on your security comparisons of XAuth and XYZ? I
> want to make sure I understand the work you put into your review.  While
> reviewing your slides, I was not following a number of your statements. For
> example:
>
> In your first slide:
>
> A) you stated that "XAuth Relies heavily on OAuth2.0, using Bearer token
> and adding cryptographic (e.g.JOSE) functions after-the-fact". Both XAuth
> and XYZ support bearer tokens for calling an RS. I'm not clear how this
> feature is different in XAuth.
>

Sure, XAuth punts the use of security off in a section and is not more
integrated in the approach.  That's how OAUth is now and it's something
that really should be fixed.  Making it clear that security is an
afterthought makes it an afterthought for developer and implementers.
Industry is moving towards built-in intrinsic security.

You can do this just as easily, but XYZ mentioned security in the
flows/sequences as an inherent part of each.   While it may not be perfect
yet, the theme was there.  The references to exchange of a key in section 2
and 3 with an editor note that this needs work are the first places the
idea of embedding begins.

The value generated in the access token doesn't explicitly use crypto, but
could.  This is something to consider.
Section 4.4.2. - uses a HASH, but an HMAC or KMAC could be used.  This is
in the feedback I will be posting.

Section 7 calls explicitly for use of a JWS and authorization values.

Section 8 provides more explicit guidance for add-on, but it's not in a
registry or another draft - part of this work.

Section 13 points to the need for more work, acknowledging multiple ways to
explore supporting security directly in the protocol.





> B) What parts of XYZ did you view as "Builds security into the protocol as
> opposed to adding it in later (e.g. OAuth2.0 bearer token + JWT)"?
>
See above.  It's a lot more clear than the single reference in XAuth.


>
> C) "Interaction flows defined, focus more on security with cryptographic
> requirements and examples included" -- there some cryptography in the
> redirect flow, but not in the others. In my opinion, the cryptography in
> the redirect flow does not add any value, and just complicates the
> protocol.
>
> Perhaps you can point to sections in each draft?
>
See above.

Best regards,
Kathleen


>
> Thanks!
>
> /Dick
>
>
>
>
> --
> Txauth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/txauth
>


-- 

Best regards,
Kathleen