[OAUTH-WG] Bls: OAuth Digest, Vol 74, Issue 10

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

‎

Dikirim dari ponsel cerdas BlackBerry 10 saya dengan jaringan Telkomsel.
  Pesan Asli  
Dari: [e-mail]
Terkirim: Selasa, 2 Desember 2014 18.30
Ke: [e-mail]
Balas Ke: [e-mail]
Perihal: OAuth Digest, Vol 74, Issue 10

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: OAuth in the news again.... (Bill Mills)
   2. Re: OAuth in the news again.... (Nat Sakimura)
   3. Re: OAuth in the news again.... (Bill Mills)
   4. Review of draft-ietf-oauth-introspection-01 (Hannes Tschofenig)
   5. Re: Review of draft-ietf-oauth-introspection-01 (Sergey Beryozkin)


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

Message: 1
Date: Tue, 2 Dec 2014 00:51:38 +0000 (UTC)
From: Bill Mills <[e-mail]>
To: Nat Sakimura <[e-mail]>,  Hannes Tschofenig
        <[e-mail]>,  John Bradley <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: Re: [OAUTH-WG] OAuth in the news again....
Message-ID:
        <[e-mail]>
        
Content-Type: text/plain; charset="utf-8"

Mis-stated perhaps, but it's highlighting a core problem we punt on at the protocol layer. ?FB as the example here tries to make teh friction of using a FB login as low as possible, and so the user consent stuff is dialed down to the very minimum of acceptable. ?This is the common pattern, get a user consent and you're covered legally and then the drive is to make that consent as minimally invasive (read effective) as possible.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ietf.org/mail-archive/web/oauth/attachments/20141202/323a17ab/attachment.html>

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

Message: 2
Date: Tue, 02 Dec 2014 01:02:44 +0000
From: Nat Sakimura <[e-mail]>
To: Bill Mills <[e-mail]>, Hannes Tschofenig
        <[e-mail]>,  John Bradley <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: Re: [OAUTH-WG] OAuth in the news again....
Message-ID:
        <CABzCy2C_sOP23rjXj-3FtJ5=[e-mail]>
Content-Type: text/plain; charset="utf-8"

Indeed, and there are commercial incentives for it.
I have doubts about the legal effectiveness of such consent but that is the
de-facto situation right now.
On the longer run, there are initiatives like information sharing and
consent WG at Kantara and ISO/IEC SC 27/WG 5 study group on notice and
consent which hopefully would emerge with a better model but that only
helps the future and not now.

Do you have some suggestions to help the situation in the mean time?

On Tue Dec 02 2014 at 9:51:39 Bill Mills <[e-mail]> wrote:

> Mis-stated perhaps, but it's highlighting a core problem we punt on at the
> protocol layer.  FB as the example here tries to make teh friction of using
> a FB login as low as possible, and so the user consent stuff is dialed down
> to the very minimum of acceptable.  This is the common pattern, get a user
> consent and you're covered legally and then the drive is to make that
> consent as minimally invasive (read effective) as possible.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ietf.org/mail-archive/web/oauth/attachments/20141202/fd497aa9/attachment.html>

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

Message: 3
Date: Tue, 2 Dec 2014 01:05:11 +0000 (UTC)
From: Bill Mills <[e-mail]>
To: Nat Sakimura <[e-mail]>,  Hannes Tschofenig
        <[e-mail]>,  John Bradley <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: Re: [OAUTH-WG] OAuth in the news again....
Message-ID:
        <[e-mail]>
        
Content-Type: text/plain; charset="utf-8"

I think the motion here is going to be social/legal and not standards based. ?We can preach on this all we want, but in the end folks like the EFF and major privacy watchdogs will carry the water here. 

     On Monday, December 1, 2014 5:02 PM, Nat Sakimura <[e-mail]> wrote:
   

 Indeed, and there are commercial incentives for it.?
I have doubts about the legal effectiveness of such consent but that is the de-facto situation right now.?On the longer run, there are initiatives like information sharing and consent WG at Kantara and ISO/IEC SC 27/WG 5 study group on notice and consent which hopefully would emerge with a better model but that only helps the future and not now.?
Do you have some suggestions to help the situation in the mean time??
On Tue Dec 02 2014 at 9:51:39 Bill Mills <[e-mail]> wrote:

Mis-stated perhaps, but it's highlighting a core problem we punt on at the protocol layer.? FB as the example here tries to make teh friction of using a FB login as low as possible, and so the user consent stuff is dialed down to the very minimum of acceptable.? This is the common pattern, get a user consent and you're covered legally and then the drive is to make that consent as minimally invasive (read effective) as possible.


   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ietf.org/mail-archive/web/oauth/attachments/20141202/77baa725/attachment.html>

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

Message: 4
Date: Tue, 02 Dec 2014 12:23:20 +0100
From: Hannes Tschofenig <[e-mail]>
To: "[e-mail]" <[e-mail]>
Subject: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01
Message-ID: <[e-mail]>
Content-Type: text/plain; charset="utf-8"

Hi Justin,

I have a few remarks regarding version -01 of the token introspection
document.

* Terminology

The token introspection protocol is a client-server protocol but the
term "client" already has a meaning in OAuth. Here the client of the
token introspection protocol is actually the resource server. I believe
it would make sense to clarify this issue in the terminology section or
in the introduction. Maybe add a figure (which you could copy from
Figure 4 of
http://www.ietf.org/id/draft-ietf-oauth-pop-architecture-00.txt.

Maybe you want to call these two parties, the introspection client and
the introspection server.

* Scope

I think the document needs to be very clear that is only applicable to
bearer tokens (and not to PoP tokens). This issue was raised at the last
IETF meeting as well.

* Meta-Information

You have replicated a lot of the claims defined in
https://tools.ietf.org/html/draft-ietf-oauth-json-web-token-31
and I am wondering why you have decided to not just re-use the entire
registry from JWT?

If you want to create a separate registry (which I wouldn't recommend)
then you have to put text into the IANA consideration section.

When you write:

"
The endpoint MAY allow other parameters to provide further context to
the query.
"

You could instead write that the token introspection MUST ignore any
parameters from the request message it does not understand.

Of course, there is the question whether any of those would be security
critical and hence ignoring them would cause problems?!

* Security

The requirement for authenticating the party issuing the introspection
request to the token introspection endpoint is justified in the security
and the privacy consideration section. The security threat is that an
attacker could use the endpoint to testing for tokens. The privacy
threat is that a resource server learns about the content of the token,
which may contain personal data. I see the former as more dangerous than
the latter since a legitimate resource server is supposed to learn about
the authorization information in the token. An attacker who had gotten
hold of tokens will not only learn about the content of the token but he
will also be able to use it to get access to the protected resource itself.

In any case, to me this sounds like mutual authentication should be
mandatory to implement. This is currently not the case. On top of that
there is single technique mandatory-to-implement outlined either (in
case someone wants to use it). That's in general not very helpful from
an interoperability point of view. Yet another thing to agree on between
the AS and the RS.

* SHOULDs

This is my usual comment that any SHOULD statement should give the
reader enough information about the trade-off decision he has to make.
When should he implement something and when should he skip it?

* Minor items

You write:

"
These include using
   structured token formats such as JWT [JWT] or SAML [[ Editor's Note:
   Which SAML document should we reference here? ]] and proprietary
   inter-service communication mechanisms (such as shared databases and
   protected enterprise service buses) that convey token information.
"

Just reference the JWT since that's what we standardize.

* 'Active' claim

you write:
"
   active  REQUIRED.  Boolean indicator of whether or not the presented
      token is currently active.  The authorization server determines
      whether and when a given token is in an active state.
"

Wouldn't it make more sense to return an error rather than saying that
this token is not active.

* Capitalization

Reading through the text I see bearer token/Bearer Token, Client/client,
etc. issue.

* AS <-> RS relationship

You write:
"
   Since
   OAuth 2.0 [RFC6749] defines no direct relationship between the
   authorization server and the protected resource, only that they must
   have an agreement on the tokens themselves, there have been many
   different approaches to bridging this gap.
"

I am not sure what you mean by "defines no relationship" between the AS
and the RS. Of course, there is a relationship. The AS issues tokens for
access for a specific RS. The RS needs to understand the tokens or if it
does not understand them it needs to know which AS to interact with to
learn about the content.

In a nutshell, I am not sure what you want to say with this paragraph
particularly since you state that they have to have an agreement about
the tokens.


Ciao
Hannes

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 513 bytes
Desc: OpenPGP digital signature
URL: <http://www.ietf.org/mail-archive/web/oauth/attachments/20141202/40efff2f/attachment.asc>

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

Message: 5
Date: Tue, 02 Dec 2014 11:30:38 +0000
From: Sergey Beryozkin <[e-mail]>
To: [e-mail]
Subject: Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01
Message-ID: <[e-mail]>
Content-Type: text/plain; charset=windows-1252; format=flowed

Hi Hannes
On 02/12/14 11:23, Hannes Tschofenig wrote:
> Hi Justin,
>
> I have a few remarks regarding version -01 of the token introspection
> document.
>
> * Terminology
>
> The token introspection protocol is a client-server protocol but the
> term "client" already has a meaning in OAuth. Here the client of the
> token introspection protocol is actually the resource server. I believe
> it would make sense to clarify this issue in the terminology section or
> in the introduction. Maybe add a figure (which you could copy from
> Figure 4 of
> http://www.ietf.org/id/draft-ietf-oauth-pop-architecture-00.txt.
>
> Maybe you want to call these two parties, the introspection client and
> the introspection server.
>
> * Scope
>
> I think the document needs to be very clear that is only applicable to
> bearer tokens (and not to PoP tokens). This issue was raised at the last
> IETF meeting as well.
>
Interesting, I was reading the doc yesterday and thought it was good it 
was not talking about specific access token types :-)

I wonder why a pop token can not be introspected in the interoperable 
way as per the text for the resource server to tale the authorization 
decision ?

Thanks, Sergey

> * Meta-Information
>
> You have replicated a lot of the claims defined in
> https://tools.ietf.org/html/draft-ietf-oauth-json-web-token-31
> and I am wondering why you have decided to not just re-use the entire
> registry from JWT?
>
> If you want to create a separate registry (which I wouldn't recommend)
> then you have to put text into the IANA consideration section.
>
> When you write:
>
> "
> The endpoint MAY allow other parameters to provide further context to
> the query.
> "
>
> You could instead write that the token introspection MUST ignore any
> parameters from the request message it does not understand.
>
> Of course, there is the question whether any of those would be security
> critical and hence ignoring them would cause problems?!
>
> * Security
>
> The requirement for authenticating the party issuing the introspection
> request to the token introspection endpoint is justified in the security
> and the privacy consideration section. The security threat is that an
> attacker could use the endpoint to testing for tokens. The privacy
> threat is that a resource server learns about the content of the token,
> which may contain personal data. I see the former as more dangerous than
> the latter since a legitimate resource server is supposed to learn about
> the authorization information in the token. An attacker who had gotten
> hold of tokens will not only learn about the content of the token but he
> will also be able to use it to get access to the protected resource itself.
>
> In any case, to me this sounds like mutual authentication should be
> mandatory to implement. This is currently not the case. On top of that
> there is single technique mandatory-to-implement outlined either (in
> case someone wants to use it). That's in general not very helpful from
> an interoperability point of view. Yet another thing to agree on between
> the AS and the RS.
>
> * SHOULDs
>
> This is my usual comment that any SHOULD statement should give the
> reader enough information about the trade-off decision he has to make.
> When should he implement something and when should he skip it?
>
> * Minor items
>
> You write:
>
> "
> These include using
>     structured token formats such as JWT [JWT] or SAML [[ Editor's Note:
>     Which SAML document should we reference here? ]] and proprietary
>     inter-service communication mechanisms (such as shared databases and
>     protected enterprise service buses) that convey token information.
> "
>
> Just reference the JWT since that's what we standardize.
>
> * 'Active' claim
>
> you write:
> "
>     active  REQUIRED.  Boolean indicator of whether or not the presented
>        token is currently active.  The authorization server determines
>        whether and when a given token is in an active state.
> "
>
> Wouldn't it make more sense to return an error rather than saying that
> this token is not active.
>
> * Capitalization
>
> Reading through the text I see bearer token/Bearer Token, Client/client,
> etc. issue.
>
> * AS <-> RS relationship
>
> You write:
> "
>     Since
>     OAuth 2.0 [RFC6749] defines no direct relationship between the
>     authorization server and the protected resource, only that they must
>     have an agreement on the tokens themselves, there have been many
>     different approaches to bridging this gap.
> "
>
> I am not sure what you mean by "defines no relationship" between the AS
> and the RS. Of course, there is a relationship. The AS issues tokens for
> access for a specific RS. The RS needs to understand the tokens or if it
> does not understand them it needs to know which AS to interact with to
> learn about the content.
>
> In a nutshell, I am not sure what you want to say with this paragraph
> particularly since you state that they have to have an agreement about
> the tokens.
>
>
> Ciao
> Hannes
>
>
>
> _______________________________________________
> 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 74, Issue 10
*************************************