<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<font face="Arial">wrt # of steps<br>
<br>
Code flow<br>
<br>
1) send browser to AS2<br>
2) collect consent<br>
3) redirect browser to TA with code<br>
4) exchange code for AT (+RT?)<br>
<br>
Assertion flow<br>
</font><br>
<font face="Arial"><font face="Arial">1) send browser to AS2<br>
2) collect consent<br>
3) redirect browser to TA with nothing<br>
4) exchange IT for AT<br>
<br>
paul<br>
<br>
</font></font>
<div class="moz-cite-prefix">On 4/9/14, 9:19 AM, John Bradley wrote:<br>
</div>
<blockquote
cite="mid:F221A097-9229-4E43-BF66-68015B04D571@ve7jtb.com"
type="cite">
<meta http-equiv="Context-Type" content="text/html;
charset=windows-1252">
The advantage of none is that it is more secure.
<div><br>
</div>
<div>There is no chance that code will be intercepted by another
application on the device. The code response is redirected
through the browser. </div>
<div>The code would need to be exchanged at the AS2 token endpoint
for the AT by the client but it typically would not be a
confidential client of AS2 never mind benefiting from additional
security from the TA having a strong relationship with AS1.</div>
<div><br>
</div>
<div>The other problem for the code flow is that AS2 needs to
provide a refresh token (cutting AS1 out of the refresh flow)
or go through the hole bootstrap web redirect process every
time the TA needs a new AT for RS2.</div>
<div><br>
</div>
<div>Using the assertion flows the TA can be strongly
authenticated by AS1 for each assertion, and AS1 has the ability
to apply policy eg the device is now in Chile but the user is
logged in to a computer in there office so perhaps no assertion
for the TA. If the assertion for the 3rd party is granted AS2
has a fresh assertion that the AT has been authenticated and
authorized, then based on that plus any authentication context
passed in the assertion AS2, AS2 decides to issue a AT for that
subject based on previous consent.</div>
<div><br>
</div>
<div>I don't think that using the assertion flow adds additional
web redirects for consent and it removes many steps for refresh
of the AT where AS1 is maintaining control of the overall
security. (AS1 can revoke any downstream AS )</div>
<div><br>
</div>
<div>John B.</div>
<div>
<div>
<div>On Apr 9, 2014, at 6:51 AM, Mike Varley <<a
moz-do-not-send="true"
href="mailto:mike.varley@securekey.com">mike.varley@securekey.com</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<div>
I pulled this from the OAuth 2.0 Multiple Response Types
spec:
<div><br>
</div>
<div>(in case others haven't seen it)</div>
<div><br>
</div>
<div>---</div>
<div>none<br>
When supplied as the response_type parameter in an OAuth
2.0 Authorization Request, the Authorization Server
SHOULD NOT return an OAuth 2.0 Authorization Code,
Access Token, Access Token Type, or ID Token in a
successful response to the grant request. If
a redirect_uri is supplied, the User Agent SHOULD be
redirected there after granting or denying access. The
request MAY include a state parameter, and if so, the
Authorization Server MUST echo its value as a response
parameter when issuing either a successful response
or an error response. The default Response Mode for this
Response Type is the query encoding. Both successful and
error responses SHOULD be returned using the supplied
Response Mode, or if none is supplied, using the default
Response Mode.<br>
---</div>
<div><br>
</div>
<div>So it is (now) clear (to me) that the state would
have to be maintained by AS2 linking the consent via the
SSO token and the access token grant request with the
id_token.</div>
<div><br>
</div>
<div>This doesn't seem to reduce the number of round
trips, however (i.e., what is the advantage of using the
'none' response_type?)</div>
<div><br>
</div>
<div>MV</div>
<div><br>
</div>
<div> </div>
<div><br>
<div>
<div>On Apr 9, 2014, at 8:34 AM, Mike Varley <<a
moz-do-not-send="true"
href="mailto:mike.varley@securekey.com">mike.varley@securekey.com</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<div>
This is what I understood the proposal to be - but
I don't understand how the browser getting nothing
provides the TA with any assurance it can request
an AT from AS2.
<div><br>
</div>
<div>If the IT was passed to AS2 during consent,
then I suppose AS2 could keep some internal
state as to the consent granted when an access
token is requested… </div>
<div><br>
</div>
<div>MV<br>
<div><br>
</div>
<div><br>
<div>
<div>On Apr 8, 2014, at 4:14 PM, Paul Madsen
<<a moz-do-not-send="true"
href="mailto:paul.madsen@gmail.com">paul.madsen@gmail.com</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<div>for comparison, John's proposed model<br>
<br>
<a moz-do-not-send="true"
class="moz-txt-link-freetext"
href="http://www.websequencediagrams.com/cgi-bin/cdraw?lz=cGFydGljaXBhbnQgYnJvd3NlcgoACAxUQQACDU4AAQ5BUzEAAg5wcEluZm8AFQ8yAEUNUlMyCgoKVEEtPkFTMTogZ2V0IHVzZXIgYXV0aGVudGljYXRlZApBUzEtPlRBOiBSVCxBVCwgSVQALQcAXAYAMwVCb290c3RyYXAoQVQpCgB1BwAwBmJvbwAVBVVSTABmBgCBVQcAFQUALwYAFgUAgWwHAIEFBwAODgB-BQAvCXJlZGlyZWN0IHRvIEFTMihzY29wZSArIFNTTyB0b2tlbikAQQ0yOgCBTAV6cmVxdWVzdAApBisAIQxub3RlIG92ZXIgACkFdmFsaWRhdGUARwoKCkFTMgCBLwtjb25zZW4ARAcpPwBfEHllcwAiEHJldHVybiBub3RoaW5nAIFjC1RBOgANCQCDBAYyOiBleGNoYW5nZSBJVAB0BlRBOiBBAIJxB04ABgZOQS0-UlMyOiBSRVNUIGNhbGwgAIJ4BQoKCgoKAAEF&s=patent">http://www.websequencediagrams.com/cgi-bin/cdraw?lz=cGFydGljaXBhbnQgYnJvd3NlcgoACAxUQQACDU4AAQ5BUzEAAg5wcEluZm8AFQ8yAEUNUlMyCgoKVEEtPkFTMTogZ2V0IHVzZXIgYXV0aGVudGljYXRlZApBUzEtPlRBOiBSVCxBVCwgSVQALQcAXAYAMwVCb290c3RyYXAoQVQpCgB1BwAwBmJvbwAVBVVSTABmBgCBVQcAFQUALwYAFgUAgWwHAIEFBwAODgB-BQAvCXJlZGlyZWN0IHRvIEFTMihzY29wZSArIFNTTyB0b2tlbikAQQ0yOgCBTAV6cmVxdWVzdAApBisAIQxub3RlIG92ZXI!
gACkFdmFsa
WRhdGUARwoKCkFTMgCBLwtjb25zZW4ARAcpPwBfEHllcwAiEHJldHVybiBub3RoaW5nAIFjC1RBOgANCQCDBAYyOiBleGNoYW5nZSBJVAB0BlRBOiBBAIJxB04ABgZOQS0-UlMyOiBSRVNUIGNhbGwgAIJ4BQoKCgoKAAEF&s=patent</a><br>
<br>
<div class="moz-cite-prefix">On 4/8/14,
3:49 PM, John Bradley wrote:<br>
</div>
<blockquote
cite="mid:EFDEFAB2-9E37-4EFF-AD21-90EE225DA5EF@ve7jtb.com"
type="cite">
I was thinking of using the
response_type=none for the outh flow
to AS2 simply to collect consent.
<div><br>
</div>
<div>The JWT or SAML assertion flow
would be used to get the access
token from AS2. The downside is
that AS2 needs to support the
assertion flow but the upside is
that AS1 has the ability to revoke
access without going thorough web
redirects each time the AT needs to
be refreshed.</div>
<div><br>
</div>
<div><br>
<div>
<div>On Apr 8, 2014, at 1:35 PM,
Paul Madsen <<a
moz-do-not-send="true"
href="mailto:paul.madsen@gmail.com">paul.madsen@gmail.com</a>>
wrote:</div>
<br
class="Apple-interchange-newline">
<blockquote type="cite">
<div>I think this wsd describes
John's model<br>
<br>
<a moz-do-not-send="true"
class="moz-txt-link-freetext"
href="http://www.websequencediagrams.com/cgi-bin/cdraw?lz=cGFydGljaXBhbnQgYnJvd3NlcgoACAxUQQACDU4AAQ5BUzEAAg5wcEluZm8AFQ8yAEUNUlMyCgoKVEEtPkFTMTogZ2V0IHVzZXIgYXV0aGVudGljYXRlZApBUzEtPlRBOiBSVCxBVAApBwBYBgAvBUJvb3RzdHJhcChBVCkKAHEHACwGYm9vABUFVVJMAGIGAIFRBwAVBQAvBgAWBQCBaAcAgQEHAA4OAHoFAC8JcmVkaXJlY3QgdG8gQVMyKHNjb3BlICsgU1NPIHRva2VuKQBBDTI6AIFIBXpyZXF1ZXN0ACkGKwAhDG5vdGUgb3ZlciAAKQV2YWxpZGF0ZQBHCgoKQVMyAIEvC2NvbnNlbgBEByk_AF8QeWVzACIQcmV0dXJuIGNvZGUgAIFhC1RBOgAPBQCCegcyOiBleGNoYW5nZQARBgByBVRBOiBhY2Nlc3MAgQYIVEEtPk4ABhBOQS0-UlM6IFJFU1QgY2FsbCAoACoMKQoKCgoKCgABBQ&s=patent">http://www.websequencediagrams.com/cgi-bin/cdraw?lz=cGFydGljaXBhbnQgYnJvd3NlcgoACAxUQQACDU4AAQ5BUzEAAg5wcEluZm8AFQ8yAEUNUlMyCgoKVEEtPkFTMTogZ2V0IHVzZXIgYXV0aGVudGljYXRlZApBUzEtPlRBOiBSVCxBVAApBwBYBgAvBUJvb3RzdHJhcChBVCkKAHEHACwGYm9vABUFVVJMAGIGAIFRBwAVBQAvBgAWBQCBaAcAgQEHAA4OAHoFAC8JcmVkaXJlY3QgdG8gQVMyKHNjb3BlICsgU1NPIHRva2VuKQBBDTI6AIFIBXpyZXF1ZXN0ACkGKwAhDG5vdGUgb3ZlciAAKQV2YWx
pZGF0ZQBHCgoKQVMyAIEvC2NvbnNlbgBEByk_AF8QeWVzACIQcmV0dXJuIGNvZGUgAIFhC1RBOgAPBQCCegcyOiBleGNoYW5nZQARBgByBVRBOiBhY2Nlc3MAgQYIVEEtPk4ABhBOQS0-UlM6IFJFU1QgY2FsbCAoACoMKQoKCgoKCgABBQ&s=patent</a><br>
<br>
Question - in the step that
John refers to as 'trigger the
IdP initiated login via
Connect or SAML' - what
support is there for an
authenticated authz request?<br>
<br>
Distinct from how the browser
gets sent to AS2 is what AS2
returns - in this case a code,
and the TA exchanges that code
for the desired AT ( to be
handed to the native app)<br>
<br>
John was advocating a
different model<br>
<br>
paul<br>
<br>
<div class="moz-cite-prefix">On
4/8/14, 2:46 PM, John
Bradley wrote:<br>
</div>
<blockquote
cite="mid:18BF96E6-66B3-4811-9718-C24D4273709B@ve7jtb.com"
type="cite">
For bootstrapping a web
session in SAML as an
example you could directly
create a IdP initiated login
URI + post body and have the
browser send that to the
third party AS directly.
<div>I think that is more
problematic from a
security perspective as
there is no way for the
home AS to say compare the
ip address of the browser
with the ip address of the
TA or make use of other
authentication factors.</div>
<div><br>
</div>
<div>Logically I prefer to
have the TA bootstrap the
browser to itself and from
there trigger the IdP
initiated login via
Connect or SAML. That is
the only way you can do a
IdP initiated login with
connect, otherwise the
user needs to authenticate
to there home AS in the
browser somewhat defeating
the point.</div>
<div><br>
</div>
<div><br>
</div>
<div>
<div>
<div>On Apr 8, 2014, at
12:36 PM, Paul Madsen
<<a
moz-do-not-send="true"
href="mailto:paul.madsen@gmail.com">paul.madsen@gmail.com</a>> wrote:</div>
<br
class="Apple-interchange-newline">
<blockquote type="cite">
<div>hi Mike, inline<br>
<br>
paul<br>
<br>
<div
class="moz-cite-prefix">On
4/7/14, 9:19 AM,
Mike Varley wrote:<br>
</div>
<blockquote
cite="mid:78F7F7C2-7C13-43C2-9984-0AF8743358C4@securekey.com"
type="cite">
A couple
comments/questions:
<div>1) what is
the 'API'
endpoint the
bootstrap URL
request is going
to? Is this the
RS?</div>
</blockquote>
would be the AppInfo
endpoint (hosted by
AS1) that the NAPPS
spec describes<br>
<br>
To obtain
application metadata
information, the <em>TA</em>
MAY make a GET or
POST request to the
AppInfo Endpoint.<br>
<br>
<br>
<blockquote
cite="mid:78F7F7C2-7C13-43C2-9984-0AF8743358C4@securekey.com"
type="cite">
<div>2) Seems like
a lot of
round-trips. On
mobile,
performance will
suffer</div>
</blockquote>
if the round trips
are performed only
for gathering
consent ....<br>
<blockquote
cite="mid:78F7F7C2-7C13-43C2-9984-0AF8743358C4@securekey.com"
type="cite">
<div>3) how does
consent from the
browser result
in an AT to the
App?</div>
</blockquote>
<br>
John proposed a
model where<br>
<br>
1) the TA is
delivered an
id_token targeted at
AS2<br>
2) the user agent is
sent to AS2 for
consent<br>
3) once consent is
obtained, the TA
exchanges the
id_token for an AT <br>
4) TA hands AT to
app<br>
<br>
<blockquote
cite="mid:78F7F7C2-7C13-43C2-9984-0AF8743358C4@securekey.com"
type="cite">
<div><br>
</div>
<div>MV</div>
<div><br>
<div>
<div>On Apr 4,
2014, at 5:53
PM, John
Bradley <<a
moz-do-not-send="true" href="mailto:ve7jtb@ve7jtb.com">ve7jtb@ve7jtb.com</a>>
wrote:</div>
<br
class="Apple-interchange-newline">
<blockquote
type="cite">
<div
dir="auto">
<div>If the
target of the
SAML IdP
initiated
login is the
OAuth
authorization
Uri we
shouldn't need
extra
attributes in
the SAML
assertion. <br>
<br>
Sent from my
iPhone</div>
<div><br>
On Apr 4,
2014, at 3:16
PM, Paul
Madsen <<a
moz-do-not-send="true" href="mailto:paul.madsen@gmail.com">paul.madsen@gmail.com</a>>
wrote:<br>
<br>
</div>
<blockquote
type="cite">I
dont think we
should
preclude
IdP-init SAML
into the AS2
consent page -
for those SaaS
currently set
up as SAML SPs
& OAuth AS<br>
<br>
implying us
defining a
scope param on
the SAML
Response?<br>
<br>
<br>
<div
class="moz-cite-prefix">On
4/4/14, 2:16
PM, John
Bradley wrote:<br>
</div>
<blockquote
cite="mid:0B8F5110-CD04-4ACC-8E1F-D2B03B3E5AE1@ve7jtb.com"
type="cite">
Yes.
<div><br>
</div>
<div>There are
two options I
can think of
for the last
step of AS2
collecting
consent.</div>
<div><br>
</div>
<div>The
request can
have a
response_type
of code and
the TA gets
back a code
that it can
use to get a
AT from the
AS2 token
endpoint. </div>
<div><br>
</div>
<div>The other
would be to
make the call
to AS2 with a
response-type
of "none" just
to collect
consent,
getting back
nothing.</div>
<div>The TA
would then use
the JWT
assertion flow
to exchange a
JWT for the
access token.</div>
<div><br>
</div>
<div>I think
the second
option is more
secure and
allows a JWT
issued by AS1
to be used
instead of a
refresh token
issued by AS2.
The advantage
is that AS1
has the
ability to
revoke access
to the
resource
without
needing a
separate API
to AS2.</div>
<div><br>
</div>
<div>John B.</div>
<div><br>
</div>
<div><br>
<div>
<div>On Apr 4,
2014, at 2:00
PM, Paul
Madsen <<a
moz-do-not-send="true" href="mailto:paul.madsen@gmail.com">paul.madsen@gmail.com</a>>
wrote:</div>
<br
class="Apple-interchange-newline">
<blockquote
type="cite">
<div>John,
something like
<br>
<br>
<a
moz-do-not-send="true"
class="moz-txt-link-freetext"
href="http://www.websequencediagrams.com/cgi-bin/cdraw?lz=cGFydGljaXBhbnQgYnJvd3NlcgoACAxUQQACDUFTMQACDlBJABEPMgoKClRBLT5BUzE6IGdldCB1c2VyIGF1dGhlbnRpY2F0ZWQKQVMxLT5UQTogUlQsQVQAKQdQSQArBUJvb3RzdHJhcChBVCkKQVBJACQGYm9vABEFVVJMAFoGAIEmBwAVBQArBgAWBQCBPQcAeQcADg4AcgUALwlyZWRpcmVjdCB0byBBUzIoaWRfdG9rZW4sc2NvcGUpAD4NMjoAgT0FenJlcXVlc3QAGhJub3RlIG92ZXIgACgFdmFsaWRhdGUgAE0ICgpBUzIAgSoLY29uc2VudCgAZgY_CgoKCgo&s=patent">http://www.websequencediagrams.com/cgi-bin/cdraw?lz=cGFydGljaXBhbnQgYnJvd3NlcgoACAxUQQACDUFTMQACDlBJABEPMgoKClRBLT5BUzE6IGdldCB1c2VyIGF1dGhlbnRpY2F0ZWQKQVMxLT5UQTogUlQsQVQAKQdQSQArBUJvb3RzdHJhcChBVCkKQVBJACQGYm9vABEFVVJMAFoGAIEmBwAVBQArBgAWBQCBPQcAeQcADg4AcgUALwlyZWRpcmVjdCB0byBBUzIoaWRfdG9rZW4sc2NvcGUpAD4NMjoAgT0FenJlcXVlc3QAGhJub3RlIG92ZXIgACgFdmFsaWRhdGUgAE0ICgpBUzIAgSoLY29uc2VudCgAZgY_CgoKCgo&s=patent</a><br>
<br>
<br>
<div
class="moz-cite-prefix">On
4/4/14, 1:42
PM, John
Bradley wrote:<br>
</div>
<blockquote
cite="mid:50B3AAE5-5023-422A-B5B4-061B0FA1690A@ve7jtb.com"
type="cite">
I was thinking
of a bootstrap
URL that
trigged idP
initiated
login at AS2.
That way the
bootstrap URI
is essentially
opaque as it
is both
specified and
consumed by
the IsP/AS of
the TA.
<div><br>
</div>
<div><br>
<div>
<div>On Apr 4,
2014, at 1:26
PM, Chuck
Mortimore <<a
moz-do-not-send="true" href="mailto:cmortimore@salesforce.com">cmortimore@salesforce.com</a>>
wrote:</div>
<br
class="Apple-interchange-newline">
<blockquote
type="cite">
<div dir="ltr">Sounds
similar, yes,
although
working out a
boostrap URL
across
different ASs
might be quite
difficult in
practice</div>
<div
class="gmail_extra"><br>
<br>
<div
class="gmail_quote">On
Fri, Apr 4,
2014 at 10:25
AM, Paul
Madsen <span
dir="ltr">
<<a
moz-do-not-send="true"
href="mailto:paul.madsen@gmail.com" target="_blank">paul.madsen@gmail.com</a>></span>
wrote:<br>
<blockquote
class="gmail_quote">
<div>hey
Chuck, you
write <br>
<br>
'If the TA
were to simply
use it's
primary token
to initialize
an OAuth
authorization
request for
the scope of
the requesting
native app, we
could simplify
this whole
thing. '<br>
<br>
John had (in
this thread)
previously
proposed
something
similar <br>
<br>
'If we have a
web app
bootstrap AS1
could give a
bootstrap URI
to the App
that would
create a
authenticated
session at AS2
for the user
to do the
normal OAuth
consent flow.'<br>
<br>
I believe
John's model
accomplishes
the same thing
as your
proposal, ie
delivers the
user's browser
(in an
authenticated
state) to an
AS where
consent can be
gathered -
albeit perhaps
with more
steps<span
class="HOEnZb"><br>
<br>
paul<br>
<br>
</span>
<div>
<div
class="h5">
<div>On
4/2/14, 5:49
PM, Chuck
Mortimore
wrote:<br>
</div>
<blockquote
type="cite">
<div dir="ltr">
<div>We don't
think there
should at all
be an "implied
consent"
model (i.e.,
authentication
at the AS
authorizes the
App for
whatever it
needs).
This sound
quite
dangerous, and
don't believe
this would at
all be
suitable for a
tightly
controlled
enterprise
environment.
We do support
models that
"feel" like
this, but
consent really
isn't
implicit...It's
simply isn't
controlled or
visilbe to the
the user. We
always run the
request
through an
authorization
check, and it
is not at all
coupled to
authentication.
Picture us
checking a
role on the
AS.</div>
<div><br>
</div>
<div>As far
JIT consent
model, it's a
bit harder to
achieve when
using the
Token
Endpoint,
unless we
explicitly
specify the TA
is collecting
consent, what
to collect,
etc.
Standardizing
a consent UI
strikes me as
very
difficult.</div>
<div><br>
</div>
<div>The way
we've balanced
the two in our
environment is
to always
perform
consent on the
authorization
endpoint.
Based on the
configuration
of the app,
we're either
checking
server side
admin defined
consent, or
prompting the
user. </div>
<div><br>
</div>
<div>It's
possible we
could continue
to use this
model in NAPPS
- if we
consider the
real difficult
issue for
users is
actually
authenticating,
then
authorization
is really not
a big deal.
If the TA were
to simply use
it's primary
token to
initialize an
OAuth
authorization
request for
the scope of
the requesting
native app, we
could simplify
this whole
thing. </div>
<div><br>
</div>
<div>-cmort</div>
</div>
<div
class="gmail_extra"><br>
<br>
</div>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</blockquote>
</div>
</div>
</blockquote>
</div>
</blockquote>
</div>
</div>
</blockquote>
</blockquote>
</div>
</blockquote>
</div>
</div>
</blockquote>
</div>
</blockquote>
</div>
</div>
</blockquote>
</div>
</blockquote>
</div>
</div>
</blockquote>
<br>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</body>
</html>