Re: [OAUTH-WG] Future of PoP Work

[Ludwig Seitz]

On 2016-10-19 20:45, Hannes Tschofenig wrote:

Hi all,

two questions surfaced at the last IETF meeting, namely

1) Do we want to proceed with the symmetric implementation of PoP or,
alternatively, do we want to move it over to the ACE working group?

2) Do we want to continue the work on HTTP signing?

We would appreciate your input on these two questions.

Ciao
Hannes & Derek




Hello,

maybe my 2-cents as author of the ACE draft that needs PoP can 
contribute something here:


I would also prefer that you guys make the PoP specs and I just make a 
ACE profile on top of them. However the ACE work is moving forward and 
the PoP work at OAuth seems to be stuck.


I've currently taken what was available form draft-ietf-oauth-pop-* and 
moved the relevant text into draft-ietf-ace-oauth-authz (acknowledging 
the original authors of course), since it was unclear to me what the 
future status of the pop drafts would be.


I'm absolutely willing to remove the text again and reference an OAuth 
WG document instead, if I feel it will not significantly delay the 
progress of the ACE draft.


Hope this information helps in the decision making.


Regards,

Ludwig



--
Ludwig Seitz, PhD   SICS Swedish ICT AB
Ideon Science Park, Building Beta 2
Scheelevägen 17, SE-223 70 Lund
Phone +46(0)70-349 92 51

The RISE institutes SP, Swedish ICT and Innventia are merging in order 
to create a unified institute sector and become a stronger innovation 
partner for businesses and society. At the end of the year we will 
change our name to RISE. Read more at www.ri.se/en/about-rise




smime.p7s
Description: S/MIME Cryptographic Signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Future of PoP Work

[Blue Teazzers]

Hi everyone

On Tue, Oct 25, 2016 at 3:28 AM, Justin Richer  wrote:

> The reason that there’s a lot of discussion on headers and query
> parameters and not a lot of discussion on the content is that there’s
> nothing special for signing the body whether it’s XML or JSON or HTML: it’s
> just a hash of the entity body, sent as the “b” parameter in the JWS. The
> body is less likely to be transformed than the headers or parameters, and
> getting into “how to sign XML” or “how to sign JSON” beyond “just take the
> body as a byte array and hash it” is problematic. I don’t think we want to
> get into the business of normalization or canonicalization of the message
> body.
>
> Keep in mind that this is all for the HTTP *request* from the client and
> not the HTTP *response* from the RS.
>
>  — Justin
>
> On Oct 24, 2016, at 1:27 PM, Phil Hunt  wrote:
>
> Rather than focus on headers and URL param signing, focus on specifying
> how content is signed in the context of PoP.
>
> I think there might be a clearer path for example if we new that signing
> for application/json and application/xml worked well.
>
> As we’ve been discussing signing headers and URL params is theoretically
> do-able, but it probably has more limited use and would remain experimental.
>
> Phil
>
> @independentid
> www.independentid.com
> phil.h...@oracle.com
>
>
>
>
>
> On Oct 24, 2016, at 1:06 PM, Justin Richer  wrote:
>
> You can already sign arbitrary content using a body hash with the current
> spec.
>
>  — Justin
>
> On Oct 24, 2016, at 8:38 AM, Phil Hunt (IDM)  wrote:
>
> Maybe if we reworked the signing doc so content types like xml and json
> could be signed?
>
> This would cover for the majority of web api cases.
>
> Wonder what the advice of the http wg would be on this.
>
> Phil
>
> On Oct 24, 2016, at 8:29 AM, Samuel Erdtman  wrote:
>
> +1 on doing PoP work in this working group, including HTTP signing/MACing,
> I don´t think the old HTTP signature document was that far from useful.
>
> With the ACE work I like when it is possible to just map work done in the
> OAuth and other working groups to the more optimized protocols. Some would
> maybe say that it is sub-optimal that the protocol was not initially
> designed for the constrained environment but I think the benefit of concept
> validation from web is a bigger plus.
>
> //Samuel
>
> On Sat, Oct 22, 2016 at 7:47 PM, Justin Richer  wrote:
>
>> I believe that the PoP work should stay in the working group, and that
>> without a usable presentation mechanism such as an HTTP message signature
>> the whole work is pointless. I agree with Mike that we should learn from
>> our own mistakes — and that is precisely the direction that the current
>> HTTP signing draft took. As a result, the base level of functionality is
>> signing the token itself (with a timestamp/nonce) using the key. All of the
>> fiddly HTTP bits that trip people up? Not only are they optional, but it’s
>> explicitly declared what’s covered. Why? Because we’re learning from past
>> mistakes.
>>
>> I think that token binding is relying on a lot of “ifs” that aren’t real
>> yet, and if those “ifs” become reality then it will be to the benefit of
>> large internet companies over everyone else. Additionally, token binding in
>> OAuth is far from the simple solution that it’s being sold as. The very
>> nature of an access token goes against the original purpose of tying an
>> artifact to a single presentation channel. OAuth clients in the real world
>> need to be able to deal with multiple resource servers and dynamically
>> deployed APIs, and the token binding protocol fundamentally assumes a world
>> where two machines are talking directly to each other.
>>
>> All that said, this working group has consistently shown resistance to
>> solving this problem for many years, so the results of this query don’t at
>> all surprise me.
>>
>>  — Justin
>>
>> > On Oct 19, 2016, at 11:45 AM, Hannes Tschofenig <
>> hannes.tschofe...@gmx.net> wrote:
>> >
>> > Hi all,
>> >
>> > two questions surfaced at the last IETF meeting, namely
>> >
>> > 1) Do we want to proceed with the symmetric implementation of PoP or,
>> > alternatively, do we want to move it over to the ACE working group?
>> >
>> > 2) Do we want to continue the work on HTTP signing?
>> >
>> > We would appreciate your input on these two questions.
>> >
>> > Ciao
>> > Hannes & Derek
>> >
>> > ___
>> > OAuth mailing list
>> > OAuth@ietf.org
>> > https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
__

Re: [OAUTH-WG] Future of PoP Work

[Justin Richer]

The reason that there’s a lot of discussion on headers and query parameters and 
not a lot of discussion on the content is that there’s nothing special for 
signing the body whether it’s XML or JSON or HTML: it’s just a hash of the 
entity body, sent as the “b” parameter in the JWS. The body is less likely to 
be transformed than the headers or parameters, and getting into “how to sign 
XML” or “how to sign JSON” beyond “just take the body as a byte array and hash 
it” is problematic. I don’t think we want to get into the business of 
normalization or canonicalization of the message body. 

Keep in mind that this is all for the HTTP *request* from the client and not 
the HTTP *response* from the RS.

 — Justin

> On Oct 24, 2016, at 1:27 PM, Phil Hunt  wrote:
> 
> Rather than focus on headers and URL param signing, focus on specifying how 
> content is signed in the context of PoP.
> 
> I think there might be a clearer path for example if we new that signing for 
> application/json and application/xml worked well. 
> 
> As we’ve been discussing signing headers and URL params is theoretically 
> do-able, but it probably has more limited use and would remain experimental.
> 
> Phil
> 
> @independentid
> www.independentid.com phil.h...@oracle.com 
> 
> 
> 
> 
> 
> 
>> On Oct 24, 2016, at 1:06 PM, Justin Richer > > wrote:
>> 
>> You can already sign arbitrary content using a body hash with the current 
>> spec.
>> 
>>  — Justin
>> 
>>> On Oct 24, 2016, at 8:38 AM, Phil Hunt (IDM) >> > wrote:
>>> 
>>> Maybe if we reworked the signing doc so content types like xml and json 
>>> could be signed?  
>>> 
>>> This would cover for the majority of web api cases. 
>>> 
>>> Wonder what the advice of the http wg would be on this. 
>>> 
>>> Phil
>>> 
>>> On Oct 24, 2016, at 8:29 AM, Samuel Erdtman >> > wrote:
>>> 
 +1 on doing PoP work in this working group, including HTTP signing/MACing, 
 I don´t think the old HTTP signature document was that far from useful.
 
 With the ACE work I like when it is possible to just map work done in the 
 OAuth and other working groups to the more optimized protocols. Some would 
 maybe say that it is sub-optimal that the protocol was not initially 
 designed for the constrained environment but I think the benefit of 
 concept validation from web is a bigger plus.
 
 //Samuel
 
 On Sat, Oct 22, 2016 at 7:47 PM, Justin Richer >>> > wrote:
 I believe that the PoP work should stay in the working group, and that 
 without a usable presentation mechanism such as an HTTP message signature 
 the whole work is pointless. I agree with Mike that we should learn from 
 our own mistakes — and that is precisely the direction that the current 
 HTTP signing draft took. As a result, the base level of functionality is 
 signing the token itself (with a timestamp/nonce) using the key. All of 
 the fiddly HTTP bits that trip people up? Not only are they optional, but 
 it’s explicitly declared what’s covered. Why? Because we’re learning from 
 past mistakes.
 
 I think that token binding is relying on a lot of “ifs” that aren’t real 
 yet, and if those “ifs” become reality then it will be to the benefit of 
 large internet companies over everyone else. Additionally, token binding 
 in OAuth is far from the simple solution that it’s being sold as. The very 
 nature of an access token goes against the original purpose of tying an 
 artifact to a single presentation channel. OAuth clients in the real world 
 need to be able to deal with multiple resource servers and dynamically 
 deployed APIs, and the token binding protocol fundamentally assumes a 
 world where two machines are talking directly to each other.
 
 All that said, this working group has consistently shown resistance to 
 solving this problem for many years, so the results of this query don’t at 
 all surprise me.
 
  — Justin
 
 > On Oct 19, 2016, at 11:45 AM, Hannes Tschofenig 
 > mailto:hannes.tschofe...@gmx.net>> wrote:
 >
 > Hi all,
 >
 > two questions surfaced at the last IETF meeting, namely
 >
 > 1) Do we want to proceed with the symmetric implementation of PoP or,
 > alternatively, do we want to move it over to the ACE working group?
 >
 > 2) Do we want to continue the work on HTTP signing?
 >
 > We would appreciate your input on these two questions.
 >
 > Ciao
 > Hannes & Derek
 >
 > ___
 > OAuth mailing list
 > OAuth@ietf.org 
 > https://www.ietf.org/mailman/listinfo/oauth 
 > 
 
 
 

Re: [OAUTH-WG] Future of PoP Work

[Phil Hunt]

Rather than focus on headers and URL param signing, focus on specifying how 
content is signed in the context of PoP.

I think there might be a clearer path for example if we new that signing for 
application/json and application/xml worked well. 

As we’ve been discussing signing headers and URL params is theoretically 
do-able, but it probably has more limited use and would remain experimental.

Phil

@independentid
www.independentid.com phil.h...@oracle.com 






> On Oct 24, 2016, at 1:06 PM, Justin Richer  wrote:
> 
> You can already sign arbitrary content using a body hash with the current 
> spec.
> 
>  — Justin
> 
>> On Oct 24, 2016, at 8:38 AM, Phil Hunt (IDM) > > wrote:
>> 
>> Maybe if we reworked the signing doc so content types like xml and json 
>> could be signed?  
>> 
>> This would cover for the majority of web api cases. 
>> 
>> Wonder what the advice of the http wg would be on this. 
>> 
>> Phil
>> 
>> On Oct 24, 2016, at 8:29 AM, Samuel Erdtman > > wrote:
>> 
>>> +1 on doing PoP work in this working group, including HTTP signing/MACing, 
>>> I don´t think the old HTTP signature document was that far from useful.
>>> 
>>> With the ACE work I like when it is possible to just map work done in the 
>>> OAuth and other working groups to the more optimized protocols. Some would 
>>> maybe say that it is sub-optimal that the protocol was not initially 
>>> designed for the constrained environment but I think the benefit of concept 
>>> validation from web is a bigger plus.
>>> 
>>> //Samuel
>>> 
>>> On Sat, Oct 22, 2016 at 7:47 PM, Justin Richer >> > wrote:
>>> I believe that the PoP work should stay in the working group, and that 
>>> without a usable presentation mechanism such as an HTTP message signature 
>>> the whole work is pointless. I agree with Mike that we should learn from 
>>> our own mistakes — and that is precisely the direction that the current 
>>> HTTP signing draft took. As a result, the base level of functionality is 
>>> signing the token itself (with a timestamp/nonce) using the key. All of the 
>>> fiddly HTTP bits that trip people up? Not only are they optional, but it’s 
>>> explicitly declared what’s covered. Why? Because we’re learning from past 
>>> mistakes.
>>> 
>>> I think that token binding is relying on a lot of “ifs” that aren’t real 
>>> yet, and if those “ifs” become reality then it will be to the benefit of 
>>> large internet companies over everyone else. Additionally, token binding in 
>>> OAuth is far from the simple solution that it’s being sold as. The very 
>>> nature of an access token goes against the original purpose of tying an 
>>> artifact to a single presentation channel. OAuth clients in the real world 
>>> need to be able to deal with multiple resource servers and dynamically 
>>> deployed APIs, and the token binding protocol fundamentally assumes a world 
>>> where two machines are talking directly to each other.
>>> 
>>> All that said, this working group has consistently shown resistance to 
>>> solving this problem for many years, so the results of this query don’t at 
>>> all surprise me.
>>> 
>>>  — Justin
>>> 
>>> > On Oct 19, 2016, at 11:45 AM, Hannes Tschofenig 
>>> > mailto:hannes.tschofe...@gmx.net>> wrote:
>>> >
>>> > Hi all,
>>> >
>>> > two questions surfaced at the last IETF meeting, namely
>>> >
>>> > 1) Do we want to proceed with the symmetric implementation of PoP or,
>>> > alternatively, do we want to move it over to the ACE working group?
>>> >
>>> > 2) Do we want to continue the work on HTTP signing?
>>> >
>>> > We would appreciate your input on these two questions.
>>> >
>>> > Ciao
>>> > Hannes & Derek
>>> >
>>> > ___
>>> > OAuth mailing list
>>> > OAuth@ietf.org 
>>> > https://www.ietf.org/mailman/listinfo/oauth 
>>> > 
>>> 
>>> 
>>> ___
>>> OAuth mailing list
>>> OAuth@ietf.org 
>>> https://www.ietf.org/mailman/listinfo/oauth 
>>> 
>>> 
>>> 
>>> ___
>>> OAuth mailing list
>>> OAuth@ietf.org 
>>> https://www.ietf.org/mailman/listinfo/oauth 
>>> 
> 

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Future of PoP Work

[Justin Richer]

You can already sign arbitrary content using a body hash with the current spec.

 — Justin

> On Oct 24, 2016, at 8:38 AM, Phil Hunt (IDM)  wrote:
> 
> Maybe if we reworked the signing doc so content types like xml and json could 
> be signed?  
> 
> This would cover for the majority of web api cases. 
> 
> Wonder what the advice of the http wg would be on this. 
> 
> Phil
> 
> On Oct 24, 2016, at 8:29 AM, Samuel Erdtman  > wrote:
> 
>> +1 on doing PoP work in this working group, including HTTP signing/MACing, I 
>> don´t think the old HTTP signature document was that far from useful.
>> 
>> With the ACE work I like when it is possible to just map work done in the 
>> OAuth and other working groups to the more optimized protocols. Some would 
>> maybe say that it is sub-optimal that the protocol was not initially 
>> designed for the constrained environment but I think the benefit of concept 
>> validation from web is a bigger plus.
>> 
>> //Samuel
>> 
>> On Sat, Oct 22, 2016 at 7:47 PM, Justin Richer > > wrote:
>> I believe that the PoP work should stay in the working group, and that 
>> without a usable presentation mechanism such as an HTTP message signature 
>> the whole work is pointless. I agree with Mike that we should learn from our 
>> own mistakes — and that is precisely the direction that the current HTTP 
>> signing draft took. As a result, the base level of functionality is signing 
>> the token itself (with a timestamp/nonce) using the key. All of the fiddly 
>> HTTP bits that trip people up? Not only are they optional, but it’s 
>> explicitly declared what’s covered. Why? Because we’re learning from past 
>> mistakes.
>> 
>> I think that token binding is relying on a lot of “ifs” that aren’t real 
>> yet, and if those “ifs” become reality then it will be to the benefit of 
>> large internet companies over everyone else. Additionally, token binding in 
>> OAuth is far from the simple solution that it’s being sold as. The very 
>> nature of an access token goes against the original purpose of tying an 
>> artifact to a single presentation channel. OAuth clients in the real world 
>> need to be able to deal with multiple resource servers and dynamically 
>> deployed APIs, and the token binding protocol fundamentally assumes a world 
>> where two machines are talking directly to each other.
>> 
>> All that said, this working group has consistently shown resistance to 
>> solving this problem for many years, so the results of this query don’t at 
>> all surprise me.
>> 
>>  — Justin
>> 
>> > On Oct 19, 2016, at 11:45 AM, Hannes Tschofenig > > > wrote:
>> >
>> > Hi all,
>> >
>> > two questions surfaced at the last IETF meeting, namely
>> >
>> > 1) Do we want to proceed with the symmetric implementation of PoP or,
>> > alternatively, do we want to move it over to the ACE working group?
>> >
>> > 2) Do we want to continue the work on HTTP signing?
>> >
>> > We would appreciate your input on these two questions.
>> >
>> > Ciao
>> > Hannes & Derek
>> >
>> > ___
>> > OAuth mailing list
>> > OAuth@ietf.org 
>> > https://www.ietf.org/mailman/listinfo/oauth 
>> > 
>> 
>> 
>> ___
>> OAuth mailing list
>> OAuth@ietf.org 
>> https://www.ietf.org/mailman/listinfo/oauth 
>> 
>> 
>> 
>> ___
>> OAuth mailing list
>> OAuth@ietf.org 
>> https://www.ietf.org/mailman/listinfo/oauth 
>> 

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Future of PoP Work

[Phil Hunt (IDM)]

Maybe if we reworked the signing doc so content types like xml and json could 
be signed?  

This would cover for the majority of web api cases. 

Wonder what the advice of the http wg would be on this. 

Phil

> On Oct 24, 2016, at 8:29 AM, Samuel Erdtman  wrote:
> 
> +1 on doing PoP work in this working group, including HTTP signing/MACing, I 
> don´t think the old HTTP signature document was that far from useful.
> 
> With the ACE work I like when it is possible to just map work done in the 
> OAuth and other working groups to the more optimized protocols. Some would 
> maybe say that it is sub-optimal that the protocol was not initially designed 
> for the constrained environment but I think the benefit of concept validation 
> from web is a bigger plus.
> 
> //Samuel
> 
>> On Sat, Oct 22, 2016 at 7:47 PM, Justin Richer  wrote:
>> I believe that the PoP work should stay in the working group, and that 
>> without a usable presentation mechanism such as an HTTP message signature 
>> the whole work is pointless. I agree with Mike that we should learn from our 
>> own mistakes — and that is precisely the direction that the current HTTP 
>> signing draft took. As a result, the base level of functionality is signing 
>> the token itself (with a timestamp/nonce) using the key. All of the fiddly 
>> HTTP bits that trip people up? Not only are they optional, but it’s 
>> explicitly declared what’s covered. Why? Because we’re learning from past 
>> mistakes.
>> 
>> I think that token binding is relying on a lot of “ifs” that aren’t real 
>> yet, and if those “ifs” become reality then it will be to the benefit of 
>> large internet companies over everyone else. Additionally, token binding in 
>> OAuth is far from the simple solution that it’s being sold as. The very 
>> nature of an access token goes against the original purpose of tying an 
>> artifact to a single presentation channel. OAuth clients in the real world 
>> need to be able to deal with multiple resource servers and dynamically 
>> deployed APIs, and the token binding protocol fundamentally assumes a world 
>> where two machines are talking directly to each other.
>> 
>> All that said, this working group has consistently shown resistance to 
>> solving this problem for many years, so the results of this query don’t at 
>> all surprise me.
>> 
>>  — Justin
>> 
>> > On Oct 19, 2016, at 11:45 AM, Hannes Tschofenig 
>> >  wrote:
>> >
>> > Hi all,
>> >
>> > two questions surfaced at the last IETF meeting, namely
>> >
>> > 1) Do we want to proceed with the symmetric implementation of PoP or,
>> > alternatively, do we want to move it over to the ACE working group?
>> >
>> > 2) Do we want to continue the work on HTTP signing?
>> >
>> > We would appreciate your input on these two questions.
>> >
>> > Ciao
>> > Hannes & Derek
>> >
>> > ___
>> > OAuth mailing list
>> > OAuth@ietf.org
>> > https://www.ietf.org/mailman/listinfo/oauth
>> 
>> 
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>> 
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Future of PoP Work

[Samuel Erdtman]

+1 on doing PoP work in this working group, including HTTP signing/MACing,
I don´t think the old HTTP signature document was that far from useful.

With the ACE work I like when it is possible to just map work done in the
OAuth and other working groups to the more optimized protocols. Some would
maybe say that it is sub-optimal that the protocol was not initially
designed for the constrained environment but I think the benefit of concept
validation from web is a bigger plus.

//Samuel

On Sat, Oct 22, 2016 at 7:47 PM, Justin Richer  wrote:

> I believe that the PoP work should stay in the working group, and that
> without a usable presentation mechanism such as an HTTP message signature
> the whole work is pointless. I agree with Mike that we should learn from
> our own mistakes — and that is precisely the direction that the current
> HTTP signing draft took. As a result, the base level of functionality is
> signing the token itself (with a timestamp/nonce) using the key. All of the
> fiddly HTTP bits that trip people up? Not only are they optional, but it’s
> explicitly declared what’s covered. Why? Because we’re learning from past
> mistakes.
>
> I think that token binding is relying on a lot of “ifs” that aren’t real
> yet, and if those “ifs” become reality then it will be to the benefit of
> large internet companies over everyone else. Additionally, token binding in
> OAuth is far from the simple solution that it’s being sold as. The very
> nature of an access token goes against the original purpose of tying an
> artifact to a single presentation channel. OAuth clients in the real world
> need to be able to deal with multiple resource servers and dynamically
> deployed APIs, and the token binding protocol fundamentally assumes a world
> where two machines are talking directly to each other.
>
> All that said, this working group has consistently shown resistance to
> solving this problem for many years, so the results of this query don’t at
> all surprise me.
>
>  — Justin
>
> > On Oct 19, 2016, at 11:45 AM, Hannes Tschofenig <
> hannes.tschofe...@gmx.net> wrote:
> >
> > Hi all,
> >
> > two questions surfaced at the last IETF meeting, namely
> >
> > 1) Do we want to proceed with the symmetric implementation of PoP or,
> > alternatively, do we want to move it over to the ACE working group?
> >
> > 2) Do we want to continue the work on HTTP signing?
> >
> > We would appreciate your input on these two questions.
> >
> > Ciao
> > Hannes & Derek
> >
> > ___
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth