<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<font face="Arial">can you expand on the upside? <br>
<br>
how would the AS1 revoke the ability of the TA to get new ATs?<br>
<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
class="gmail_quote">On
Thu, Mar 20,
2014 at 1:37
PM, 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>exploring
#5 and your
scenario<br>
<br>
something like<br>
<br>
1) TA gets
user
authenticated
and obtains
refresh token
with certain
scopes<br>
2) TA somehow
knows that for
a particular
app,
additional
consent is
needed, and
that a 3rd
party AS2 has
to collect it<br>
3) TA uses its
RT to obtain
an id_token
targeted at
3rd party AS2<br>
4) TA attaches
id_token to
authz request
when browser
sent to AS2 <br>
5) AS2
collects
consent<br>
6) AS2 returns
code/token etc
to TA<br>
<br>
Different
options for
Steps #3 &
#4 exist <br>
<span><br>
paul<br>
<br>
</span>
<div>
<div>
<div>On
3/20/14, 3:44
PM, John
Bradley wrote:<br>
</div>
<blockquote
type="cite">Inline<br>
<div>
<div>On Mar
20, 2014, at
4:34 PM, Paul
Madsen <<a
moz-do-not-send="true" href="mailto:paul.madsen@gmail.com"
target="_blank">paul.madsen@gmail.com</a>>
wrote:</div>
<br>
<blockquote
type="cite">
<div>possible
permutations?<br>
<br>
Single AS<br>
1) consent
collected at
AS</div>
</blockquote>
<blockquote
type="cite">
<div> 2)
consent
collected at
TA (and
reported to AS
in access
token
request?) <br>
</div>
</blockquote>
For 2 some UI
elements need
to be
delivered to
the TA perhaps
via AppInfo<br>
<blockquote
type="cite">
<div><br>
Two ASs<br>
3) consent
collected at
AS1 (and
reported to
AS2 in
id_token?)<br>
</div>
</blockquote>
If AS 2 trusts
AS1to collect
consent it
could just
list the
scopes
granted.<br>
<blockquote
type="cite">
<div> 4)
consent
collected at
TA (and
reported to
AS2 in access
token
request?)<br>
</div>
</blockquote>
This perhaps
works if the
TA is making a
authenticated
request to
AS2. I think
3 or 5 is more
likely.<br>
<blockquote
type="cite">
<div> 5)
consent
collected at
AS2<br>
</div>
</blockquote>
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.</div>
<div><br>
</div>
<div><br>
<blockquote
type="cite">
<div>paul<br>
<br>
<div>On
3/20/14, 11:02
AM, John
Bradley wrote:<br>
</div>
<blockquote
type="cite">
<pre>I think our conversation about collecting consent was mostly focused on the basic case where the AS the TA is talking to can directly mint access tokens.
We still may need to collect user consent beyond what was agreed to at initial setup of the TA.
I think you are going one step further where the first party AS collects consent on behalf of the 3rd party AS/RS and indicates that in the id_token.
The second one is harder in that the third party AS would somehow need to communicate it's scopes out of band to the 1st party AS for collection.
John B.
On Mar 20, 2014, at 11:51 AM, Mike Varley <a moz-do-not-send="true" href="mailto:mike.varley@securekey.com" target="_blank"><mike.varley@securekey.com></a> wrote:
</pre>
<blockquote
type="cite">
<pre>Yeah, probably - something like a 'consent' field in the id_token or AppInfo response that the RS can match to the scope. Just making something up on the spot (and in no way really thought through but what the heck) maybe something like:
consent: implicit //> RS should decide if it trusts AS, or maybe query AS as to what the implied consent involves.
consent: <consent_token> //> RS should examine token to see if it matches the scope and session the token was issued to.
consent: none //> RS should explicitly ask for consent
Note that the RS will always have final say on whether to trust the AS/TA, and whether or not to explicitly collect further user consent.
This is just a thought, love to hear more ideas.
thanks,
MV
On Mar 20, 2014, at 10:39 AM, Paul Madsen <a moz-do-not-send="true" href="mailto:paul.madsen@gmail.com" target="_blank"><paul.madsen@gmail.com></a> wrote:
</pre>
<blockquote
type="cite">
<pre>Thanks Mike, yes Chuck raised some of the same concerns/points
What might a 'consent extension point' look like? Just suitable OPT mechanisms?
Paul
On 3/20/14, 10:32 AM, Mike Varley wrote:
</pre>
<blockquote
type="cite">
<pre>Hi all, sorry to have missed the meeting. I noticed that the consent question came up, and I'd like to share some of the challenges I've come across, just for consideration (again, apologies if this was covered on the call). In general, the experience has been that the various subtleties and nuances of consent can vastly complicate the model and user experience.
If you have a model of 'implied consent' (i.e., authentication at the AS authorizes the App for whatever it needs):
- may be suitable for tightly controlled Enterprise deployments
- provides a simplified user experience
- puts the user at risk of leaking data/PII
- "all-or-nothing" consent may be a barrier to entry for users
If you have a JIT consent model:
- more suitable for 'public' or general federations of Apps and Resources
- more burden on the user, as they have to authorize against each RS for each App
- usually involves more network round-trips, which on a mobile device can impose a noticeable delay
- RSs have to choose an entity to trust that consent has been collected:
-- Trust the AS has presented the user with the right scopes/terms of service
(how does the AS keep these in sync with the RS policy? Is there anything in the 'scopes' themselves that leak PII? )
-- Trust the TA that it has collected consent directly from the RS before issuing tickets to the Apps
(usually means the RS must return a 'session scope auth token' to the TA that gets embedded in the Auth Token - and AppInfo endpoint must point TA to RS consent endpoints)
-- Trust only 'yourself' (RS) meaning each App will have to present the authentication token with a _desired_ scope, and the RS must be able to collect consent itself.
(has App UI implications, as the App must now be able to render the RS consent screen)
User consent is a very important part of this kind of system, to be sure - but attempting to solve the "entire problem for all ecosystems" will probably only lead to pain and sadness ;) So I am assuming the NAPPS spec will only try to define 'consent extension points', where any particular ecosystem can expand on to fit their own consent / privacy model.
I hope this was useful.
Thanks,
MV
On Mar 20, 2014, at 8:38 AM, Paul Madsen
<a moz-do-not-send="true" href="mailto:paul.madsen@gmail.com" target="_blank"><paul.madsen@gmail.com></a>
wrote:
</pre>
<blockquote
type="cite">
<pre>Attending
Paul
John
Chuck
Ashish
1) Ashish reported back on the RSA F2F
Attending were Mike & Caleb from MSFT, some MobileIron & Airwatch folks, somebody from OneLogin
Ashish asked for people's assessment of group value. Group agreed there was a need and worthwhile
Microsoft challenging the value - claiming that something like this would be eventually be addressed by the OS vendors. Group feels the interapp piece (that the OS vendors will address) is just half the problem, the other half is the on-the-wire protocol between TA & AS
In offline conversations with John, MSFT reps agreed that there was value in defining the on-the-wire protocol.
Perhaps we can clarify that we don't intend to mandate a particular interapp protocol
Ashish adds there was agreement that we need more ISVs participating , action item was to reach out to contacts at the SaaS.
John indicates he talked to Layer7 at MWC and that they feel they have comparable functionality
2) Discussion of the different models for token-chaining, and how/where the complexity of dealing with token chaining sits - does the TA deal with the exchange, or does the app deal with the exchange
John points out the implications of the trust models, and who needs to know what?
AI - John will put together a summary of the different models and the pros/cons of each
Ashish asked about a model where the trust and token exchange happens at the AS level
Permuations appear to be
- TA asks downstream AS for AT
- Downstream app asks downstream AS for AT
- Upstream AS asks downstream AS for AT
Implications for consent gathering
2) Discussion about the use case of bridging from the TA into web app SSO
Everybody has a different way to do this
Ashish points out an issue about how to get session info into a web clip....
Different UI implications/models
AI - Paul will start a thread on the use case on the NAPPS list
3) Chuck remains concerned about the consent model - believes the spec as it is is primarily focused on authentication, and not about authz.
Different consent models differ on where the consent happens, at the TA or at the AS
John points out that this relates to the lack of the 'pre-authenticated authz request'
Chuck wants their server involved in collecting consent, and wants that to happen JIT and not a priori
John points out that this ties in with the bootstrap to browser app piece
AI - Chuck will summarize his thoughts on consent (where & when) on the list
Meeting closed
_______________________________________________
Openid-specs-native-apps mailing list
<a moz-do-not-send="true" href="mailto:Openid-specs-native-apps@lists.openid.net" target="_blank">Openid-specs-native-apps@lists.openid.net</a>
<a moz-do-not-send="true" href="http://lists.openid.net/mailman/listinfo/openid-specs-native-apps" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-native-apps</a>
</pre>
</blockquote>
<pre>_______________________________________________
Openid-specs-native-apps mailing list
<a moz-do-not-send="true" href="mailto:Openid-specs-native-apps@lists.openid.net" target="_blank">Openid-specs-native-apps@lists.openid.net</a>
<a moz-do-not-send="true" href="http://lists.openid.net/mailman/listinfo/openid-specs-native-apps" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-native-apps</a>
</pre>
</blockquote>
</blockquote>
<pre>_______________________________________________
Openid-specs-native-apps mailing list
<a moz-do-not-send="true" href="mailto:Openid-specs-native-apps@lists.openid.net" target="_blank">Openid-specs-native-apps@lists.openid.net</a>
<a moz-do-not-send="true" href="http://lists.openid.net/mailman/listinfo/openid-specs-native-apps" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-native-apps</a>
</pre>
</blockquote>
</blockquote>
<br>
</div>
</blockquote>
</div>
<br>
</blockquote>
<br>
</div>
</div>
</div>
<br>
_______________________________________________<br>
Openid-specs-native-apps
mailing list<br>
<a
moz-do-not-send="true"
href="mailto:Openid-specs-native-apps@lists.openid.net" target="_blank">Openid-specs-native-apps@lists.openid.net</a><br>
<a
moz-do-not-send="true"
href="http://lists.openid.net/mailman/listinfo/openid-specs-native-apps"
target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-native-apps</a><br>
<br>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</blockquote>
</div>
_______________________________________________<br>
Openid-specs-native-apps mailing list<br>
<a moz-do-not-send="true"
href="mailto:Openid-specs-native-apps@lists.openid.net">Openid-specs-native-apps@lists.openid.net</a><br>
<a moz-do-not-send="true"
class="moz-txt-link-freetext"
href="http://lists.openid.net/mailman/listinfo/openid-specs-native-apps">http://lists.openid.net/mailman/listinfo/openid-specs-native-apps</a><br>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</body>
</html>