[OAUTH-WG] Bls: OAuth Digest, Vol 72, Issue 78

[Panca Agus Ananda <[e-mail]>]

Dikirim dari ponsel cerdas BlackBerry 10 saya dengan jaringan Telkomsel.
Dari: [e-mail]
Terkirim: Rabu, 29 Oktober 2014 02.01
Ke: [e-mail]
Balas Ke: [e-mail]
Perihal: OAuth Digest, Vol 72, Issue 78


Send OAuth mailing list submissions to
        [e-mail]

To subscribe or unsubscribe via the World Wide Web, visit
        https://www.ietf.org/mailman/listinfo/oauth
or, via email, send a message with subject or body 'help' to
        [e-mail]

You can reach the person managing the list at
        [e-mail]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of OAuth digest..."


Today's Topics:

   1. Re: Notes from 2nd "OAuth & Authentication" Conference    Call
      (Richer, Justin P.)
   2. Re: Stephen Farrell's Discuss on
      draft-ietf-oauth-json-web-token-27: (with DISCUSS and COMMENT)
      (Sergey Beryozkin)


----------------------------------------------------------------------

Message: 1
Date: Mon, 27 Oct 2014 23:21:21 +0000
From: "Richer, Justin P." <[e-mail]>
To: Hannes Tschofenig <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: Re: [OAUTH-WG] Notes from 2nd "OAuth & Authentication"
        Conference      Call
Message-ID: <[e-mail]>
Content-Type: text/plain; charset="us-ascii"

I've been incorporating peoples' feedback into the proposed oauth.net page, and the current state is here:

https://github.com/jricher/oauth.net/blob/authentication/articles/authentication.php

Commentary has slowed down and I think the document's in reasonable. I would like to publish this as a draft version on oauth.net in the very near future (like, this week), so get comments and feedback to me on this soon. I'm going to be at IIW all week if anyone wants to back me into a corner and talk about this.

 -- Justin

On Oct 16, 2014, at 12:54 PM, Hannes Tschofenig <[e-mail]> wrote:

> Participants:
>
> * Brian Campbell
> * John Bradley
> * Derek Atkins
> * Phil Hunt
> * William Kim
> * Josh Mandel
> * Hannes Tschofenig
>
>
> Notes:
>
> Justin distributed a draft writeup and explained the reasoning behind
> it. The intended purpose is to put the write-up (after enough review) on
> oauth.net. See attachments. Justin solicited feedback from the
> conference call participants and from the working group.
>
> One discussion item was specifically related to the concept of audience
> restrictions, which comes in two flavours: (a) restriction of the access
> token regarding the resource server and (b) restriction of the id token
> regarding the client. Obviously, it is necessary to have both of these
> audience restrictions in place and to actually check them.
>
> The group then went into a discussion about the use of pseudonyms in
> authentication and the problems deployments ran into when they used
> pseudonyms together with a wide range of attributes that identified
> users nevertheless. Phil suggested to produce a write-up about this topic.
>
> Finally, the group started a discussion about potential actions for the
> OAuth working groups. Two activities were mentioned, namely to produce
> an IETF draft of the write-up Justin has prepared as a "formal" response
> to the problems with authentication using OAuth and, as a second topic,
> potential re-chartering of the OAuth working group to work on some
> solutions in this area. Hannes suggested to postpone these discussions
> and to first finish the write-up Justin had distributed.
>
> Ciao
> Hannes & Derek
> <Authentication with OAuth 2.doc><Authentication with OAuth 2.html><Authentication with OAuth 2.pdf>_______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth



------------------------------

Message: 2
Date: Tue, 28 Oct 2014 10:41:04 +0000
From: Sergey Beryozkin <[e-mail]>
To: [e-mail]
Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on
        draft-ietf-oauth-json-web-token-27: (with DISCUSS and COMMENT)
Message-ID: <[e-mail]>
Content-Type: text/plain; charset=windows-1252; format=flowed

Hi

I've found 'none' to be a useful mechanism for using JWT representations
as OAuth2 (bearer) tokens where JWT is turned into JWS with a none
algorithm and then encrypted...

Cheers, Sergey
On 23/10/14 09:58, Nat Sakimura wrote:
> I second John's message. There are many ways to achieve a desired level
> of security and one of the most popular way is to delegate it to the
> transport layer and use 'none' as the alg. If 'none' becomes non-MTI,
> then it may cause a lot of interoperability issues down the road.
>
> Adding to it, JWT can be useful in other context than security as well.
> As interoperability is one of the most important criteria, having 'none'
> as MTI seems to be a reasonable idea to me.
>
> Nat
>
> 2014-10-22 16:44 GMT-05:00 John Bradley <[e-mail]
> <mailto:[e-mail]>>:
>
>      From a JWT perspective a number of applications including connect
>     allow unsecured JWT.
>
>     I guess you are referring to sec 8 of JWT in the OAuth WG.  Some of
>     the threads you mention were in the JOSE WG relating to the JWS spec
>     and if none should be included.
>
>     To some extent the issues are not quite the same for the different
>     specs.
>
>     SAML certainly allows for unsigned documents, those are used in a
>     lot of places.  I imagine that a SAML library that could not process
>     unsigned messages would generally be considered broken.
>     That is not to say that it also needs to also support signed ones
>     and some number of trust models.
>
>     It is the same for JWT as it lives at a similar conceptual level to
>     SAML assertions.
>
>     It is better for interoperability to have all the JWT libs implement
>     "none", so that it can be supported in the many cases it may be used
>     for processing JWT protected by transport or some other mechanism,
>     and reliably reject "none" when signatures are required.
>
>     The JWT spec is not requiring JWS or JWE to implement support for
>     none,  though likely life would be easier if they did support it.
>
>     John B.
>
>
>
>     On Oct 21, 2014, at 1:36 PM, Kathleen Moriarty
>     <[e-mail]
>     <mailto:[e-mail]>> wrote:
>
>>
>>
>>     On Tue, Oct 21, 2014 at 9:16 AM, Stephen
>>     Farrell<[e-mail]
>>     <mailto:[e-mail]>>wrote:
>>
>>
>>         Hi Mike,
>>
>>         I've one remaining discuss point and a comment. See below...
>>
>>         On 14/10/14 13:50, Mike Jones wrote:
>>         > The proposed resolutions below have been included in the -28
>>         draft.  Hopefully you'll be able to clear your DISCUSSes on
>>         that basis.
>>         >
>>         > The String Comparison Rules in Section 7.3 have been
>>         expanded to talk about when the application may need
>>         canonicalization rules.
>>         >
>>         >                               Thanks again,
>>         >                               -- Mike
>>         >
>>         >> -----Original Message-----
>>         >> From: OAuth [mailto:[e-mail]
>>         <mailto:[e-mail]>] On Behalf Of Mike Jones
>>         >> Sent: Monday, October 06, 2014 7:20 PM
>>         >> To: Stephen Farrell; The IESG
>>         >> Cc:[e-mail]
>>         <mailto:[e-mail]>; draft-ietf-oauth-json-web-
>>         >>[e-mail]
>>         <mailto:[e-mail]>;[e-mail]
>>         <mailto:[e-mail]>
>>         >> Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on
>>         draft-ietf-oauth-json-
>>         >> web-token-27: (with DISCUSS and COMMENT)
>>         >>
>>         >> Thanks for tracking all of this Stephen.  Responses inline
>>         below...
>>         >>
>>         >>> -----Original Message-----
>>         >>> From: Stephen Farrell [mailto:[e-mail]
>>         <mailto:[e-mail]>]
>>         >>> Sent: Monday, October 06, 2014 2:43 PM
>>         >>> To: Mike Jones; The IESG
>>         >>> Cc:[e-mail]
>>         <mailto:[e-mail]>; draft-ietf-oauth-json-web-
>>         >>>[e-mail]
>>         <mailto:[e-mail]>;[e-mail]
>>         <mailto:[e-mail]>
>>         >>> Subject: Re: Stephen Farrell's Discuss on
>>         draft-ietf-oauth-json-web-token-27:
>>         >>> (with DISCUSS and COMMENT)
>>         >>>
>>         >>>
>>         >>> Hi Mike,
>>         >>>
>>         >>> On 06/10/14 08:54, Mike Jones wrote:
>>         >>>> Thanks for your review, Stephen.  I've added the working
>>         group to
>>         >>>> the thread so they're aware of your comments.
>>         >>>>
>>         >>>>> -----Original Message----- From: Stephen Farrell
>>         >>>>> [mailto:[e-mail]
>>         <mailto:[e-mail]>] Sent: Thursday, October
>>         02, 2014
>>         >>>>> 5:03 AM To: The IESG Cc:[e-mail]
>>         <mailto:[e-mail]>;
>>         >>>>> [e-mail]
>>         <mailto:[e-mail]>Subject: Stephen
>>         >>>>> Farrell's Discuss on draft-ietf-oauth-json-web-token-27:
>>         (with
>>         >>>>> DISCUSS and COMMENT)
>>         >>>>>
>>         >>>>> Stephen Farrell has entered the following ballot
>>         position for
>>         >>>>> draft-ietf-oauth-json-web-token-27: Discuss
>>         >>>>>
>>         >>>>> When responding, please keep the subject line intact and
>>         reply to
>>         >>>>> all email addresses included in the To and CC lines.
>>         (Feel free to
>>         >>>>> cut this introductory paragraph, however.)
>>         >>>>>
>>         >>>>>
>>         >>>>> Please refer to
>>         >>>>>http://www.ietf.org/iesg/statement/discuss-criteria.htmlfor
>>         more
>>         >>>>> information about IESG DISCUSS and COMMENT positions.
>>         >>>>>
>>         >>>>>
>>         >>>>> The document, along with other ballot positions, can be
>>         found
>>         >>>>> here:
>>         >>>>>http://datatracker.ietf.org/doc/draft-ietf-oauth-json-web-token/
>>         >>>>>
>>         >>>>>
>>         >>>>>
>>         >>>>>
>>         -------------------------------------------------------------------
>>         >>>>> --
>>         >>>>> -
>>         >>>>>
>>         >>>>>
>>         >>> DISCUSS:
>>         >>>>>
>>         -------------------------------------------------------------------
>>         >>>>> --
>>         >>>>> -
>>         >>>>>
>>         >>>>>
>>         >>>>>
>>         >>>>>
>>         >>> (1) 4.1.1 and elsewhere you say case-sensitive: the same
>>         thing I
>>         >>> raised wrt DNS
>>         >>>>> names for another JOSE spec - do you need to say those
>>         SHOULD be
>>         >>>>> [upper|lower]cased when used in these?
>>         >>>>
>>         >>>> I believe that somewhere we should say that if
>>         case-insensitive
>>         >>>> values, such as DNS names, are used when constructing
>>         "kid" values,
>>         >>>> that the application doing so needs to define a
>>         convention on the
>>         >>>> canonical case to use for the case-insensitive portions,
>>         such as
>>         >>>> lowercasing them.
>>         >>>
>>         >>> As that discussion's happening on the key draft, I'll
>>         clear it here
>>         >>> and trust you to fix if a change is the end result.
>>         >>
>>         >> Thanks
>>
>>         np
>>
>>         >>
>>         >>>>> (2) Section 8: Why is "none" MTI? That seems both broken
>>         and going
>>         >>>>> in the oppostite direction from other WGs and so should be
>>         >>>>> explicitly jusified I think. (If a good enough
>>         justification exists
>>         >>>>> that is.)
>>         >>>>
>>         >>>> It is MTI because there are several existing applications
>>         of JWTs in
>>         >>>> which both unsigned and signed representations of the
>>         JWTs are
>>         >>>> requirements.  These include draft-ietf-oauth-token-exchange,
>>         >>>> draft-hunt-oauth-v2-user-a4c, and OpenID Connect.  This
>>         is a pretty
>>         >>>> common pattern where you sign something if the recipient
>>         cares who
>>         >>>> made the statements and where you don't have to sign it
>>         either if
>>         >>>> the recipient doesn't care who made the statements
>>         >>>
>>         >>> I don't see how (non-)signers can divine non-verifier's
>>         wishes that
>>         >>> way. (Absent negotiation or a directory.)
>>         >>
>>         >> Sometimes it does occur via negotiation.  For instance, in
>>         some protocols, at
>>         >> registration time, relying parties explicitly tell identity
>>         providers what algorithms
>>         >> are acceptable to them, which may include "none".  No
>>         divination - explicit
>>         >> communication.
>>         >>
>>         >>>> or if it can tell from
>>         >>>> another secured aspect of the application protocol (typically
>>         >>>> through the use of TLS) who made the statements.  In the
>>         TLS case,
>>         >>>> the server authentication step makes a signature step
>>         unnecessary,
>>         >>>> so an Unsecured JWT is fine there.
>>         >>>
>>         >>> That's arguable IMO.
>>         >>
>>         >> I agree that it's application and context-dependent whether
>>         it's OK or not.  The
>>         >> point is that there exist some circumstances in which it is
>>         OK, and this feature is
>>         >> being used in some of those cases.
>>         >>
>>         >>> I think I'll look back over the wg thread and either hold
>>         my nose or
>>         >>
>>         >> This issue was tracked
>>         ashttp://trac.tools.ietf.org/wg/jose/trac/ticket/36.
>>         >> Karen O'Donoghue recorded this conclusion in the tracker
>>         "Note: There was
>>         >> extensive discussion on the mailing list, and the rough
>>         consensus of the working
>>         >> group was to leave "none" in the document."
>>         >>
>>         >> Discussion threads on this topic include:
>>         >> [jose] #36: Algorithm "none" should be
>>         removedhttp://www.ietf.org/mail-
>>         >> archive/web/jose/current/msg02911.html - Began Jul 31,
>>         2013  (91 messages)
>>         >> [jose] Text about applications and
>>         "alg":"none"http://www.ietf.org/mail-
>>         >> archive/web/jose/current/msg03321.html - Began Sep 3, 2013
>>         (5 messages)
>>         >>
>>         >> This issue was a topic of a special working group call on
>>         Aug 19, 2013.  The text
>>         >> discussed in the last thread and published
>>         athttps://tools.ietf.org/html/draft-
>>         >> ietf-jose-json-web-algorithms-33#section-8.5 (Unsecured JWS
>>         Security
>>         >> Considerations) was the result of the working group's
>>         decisions resulting from all
>>         >> of this discussion.
>>
>>         Thanks for all the pointers above. I read through all the (many!)
>>         Aug 19 mails and most of the `"none" should be removed" thread.
>>
>>         So I do see that there was rough consensus to keep "none" in
>>         the draft and can (with difficulty;-) hold my nose and let that
>>         pass. I do not however, see that there was consensus to make
>>         "none" MTI for this draft. I did see a bit of haggling about
>>         this draft vs. JWS but still do not see why none ought be MTI
>>         here.
>>
>>         >>
>>         >>>>> (3) Section 12: another way to handle privacy is to not include
>>         >>>>> sensitive data - I think you ought mention that as a bit of thought
>>         >>>>> along those lines can be much simpler than putting in place the key
>>         >>>>> management to handle thoughtlessly included PII.
>>         >>>>
>>         >>>> We can include a discussion of that point,
>>         >>>
>>         >>> Great. "Just say no" is workable here:-) I'll clear when we get such text.
>>         >>>
>>         >>>> but sometimes the very
>>         >>>> point of a JWT is to securely deliver PII from a verifiable party to
>>         >>>> an intended party with appropriate rights to receive it.
>>         >>>
>>         >>> Hmm. Its a moot point (so let's not argue it) but I wonder how often
>>         >>> PII is really needed for authorization with oauth. My guess would be
>>         >>> that its needed far less often than its found to be profitable
>>         >>> perhaps, or that carelessness plays a big role in using PII for such purposes.
>>
>>         I've cleared on this as you added this text:
>>
>>         "Of course, including
>>            only necessary privacy-sensitive information in a JWT is
>>         the most
>>            basic means of minimizing any potential privacy issues."
>>
>>         That seems to me like a fairly offputting way to phrase it. I'd
>>         suggest instead:
>>
>>         "Omitting privacy-sensitive information from a JWT is the
>>         simplest way of minimizing privacy issues."
>>
>>
>>     I like this wording suggestion, thanks.
>>
>>
>>         Cheers,
>>         S.
>>
>>         PS: I didn't check the comments.
>>
>>         >>>
>>         >>> S.
>>         >>>
>>         >>>
>>         >>>
>>         >>>>
>>         >>>>>
>>         -------------------------------------------------------------------
>>         >>>>> --
>>         >>>>> -
>>         >>>>>
>>         >>>>>
>>         >>> COMMENT:
>>         >>>>>
>>         -------------------------------------------------------------------
>>         >>>>> --
>>         >>>>> -
>>         >>>>>
>>         >>>>>
>>         >>>>>
>>         >>>>>
>>         >>> - abstract: 2nd sentence isn't needed here, in intro would
>>         be fine.
>>         >>>>
>>         >>>> I don't know - I think it's a big deal that the claims can be
>>         >>>> digitally signed or MACed and/or encrypted.  That's the
>>         reason we
>>         >>>> have JWTs, rather than just JSON.
>>         >>>>
>>         >>>>> - 4.1.7: maybe worth adding that jti+iss being unique
>>         enough is not
>>         >>>>> sufficient and jti alone has to meet that need. In X.509 the
>>         >>>>> issuer/serial has the equivalent property so someone
>>         might assume
>>         >>>>> sequential jti values starting at 0 are ok.
>>         >>>>
>>         >>>> Makes sense to add a warning of some kind along these
>>         lines.  I
>>         >>>> think I know the reasons you say that, but can you expand
>>         on that
>>         >>>> thought a bit before I take a stab on writing this up?  For
>>         >>>> instance, while normally true, I don't think your
>>         observation is
>>         >>>> true if a relying party will only accept tokens from a
>>         single issuer.
>>         >>>>
>>         >>>>> - section 6: yuk
>>         >>>>>
>>         >>>>> - again I think the secdir comments are being handled by
>>         Kathleen
>>         >>>>> and the authors.
>>         >>>>
>>         >>>> Again, this is there because multiple applications asked
>>         for the
>>         >>>> ability to represent content that is optionally signed,
>>         sometimes
>>         >>>> securing it another way, such as with TLS.  JWTs are used
>>         specific
>>         >>>> application protocol contexts - not in isolation.
>>         >>>>
>>         >>>> Thanks again, -- Mike
>>         >>>>
>>         >> _______________________________________________
>>         >> OAuth mailing list
>>         >>[e-mail] <mailto:[e-mail]>
>>         >>https://www.ietf.org/mailman/listinfo/oauth
>>         >
>>
>>
>>
>>
>>     --
>>
>>     Best regards,
>>     Kathleen
>
>
>     _______________________________________________
>     OAuth mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
> --
> Nat Sakimura (=nat)
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>



------------------------------

Subject: Digest Footer

_______________________________________________
OAuth mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/oauth


------------------------------

End of OAuth Digest, Vol 72, Issue 78
*************************************