<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<font face="Arial">for comparison, John's proposed model<br>
<br>
<a 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-BQAvCXJlZGlyZWN0IHRvIEFTMihzY29wZSArIFNTTyB0b2tlbikAQQ0yOgCBTAV6cmVxdWVzdAApBisAIQxub3RlIG92ZXIg
ACkFdmFsa
WRhdGUARwoKCkFTMgCBLwtjb25zZW4ARAcpPwBfEHllcwAiEHJldHVybiBub3RoaW5nAIFjC1RBOgANCQCDBAYyOiBleGNoYW5nZSBJVAB0BlRBOiBBAIJxB04ABgZOQS0-UlMyOiBSRVNUIGNhbGwgAIJ4BQoKCgoKAAEF&s=patent</a><br>
<br>
</font>
<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">
<meta http-equiv="Context-Type" content="text/html;
charset=iso-8859-1">
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>
</body>
</html>