<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Minor comment:<br>
I think the line in the "Entity statements, metadata and trust"
section,<br>
that says:<br>
<blockquote>"The <b>issued entity identifier</b> MUST be included
as the <code class="highlighter-rouge">iss</code> claim."<br>
</blockquote>
should be modified to instead say:<br>
<blockquote>"The<b> issuer entity's entity identifier</b> MUST be
included as the <code class="highlighter-rouge">iss</code> claim."<br>
</blockquote>
because, as written, I don't think the term "issued entity
identifier" is semantically<br>
meaningful.<br>
<br>
Thanks,<br>
Rich<br>
<br>
<div class="moz-cite-prefix">On 8/17/2018 5:22 AM, Steffen Klemer
via Openid-specs-ab wrote:<br>
</div>
<blockquote type="cite" cite="mid:20180817112231.0cd0754f@amsel">
<pre wrap="">Perhaps to abstract and explain this a bit more:
In the bank scenario we have a federation with many SP but one IdP and
after you registered the OpenID-Connect RP, the app, the only thing you
can do is log in at that one IdP and then use the bank's API -- do your
financial stuff. Even if you mess with the app, only user's of that
bank may log in and the bank knows *who* uses the API and whom to blame
-- you had to log in with them.
The multi-IdP federation as we have them in the edu world have another
level of trust besides the end users. Every entity, IdPs, SPs, have to
trust each other (or this is what we like them to do ;) ). An IdP only
wants to release attributes/claims to SP that are approved by the
federation. A federation operator somehow 'checks' this SP before
allowing it into the federation. This usually happens by 'checking' and
trusting the administrator or administrative entity of the SP. You
might also check the SP itself but then you have to make sure that it
wasn't changed between the check and the time of it accessing the
federation.
In the app world this would mean you have to make sure that the app
code wasn't changed and/or the operating system doesn't change the
behaviour of the app. This could only be possible with completely
locked, non-root'able smartphones which we don't have at the moment.
Otherwise this would lead to a situation where everybody could just
register his RP in the federation. And the whole idea of the trusted
3rd party in the federation would be meaningless.
You could now construct a scenario where a user first has to log in
somewhere and with these credentials register the app as an RP in the
federation but 1st of all you get the same problems only one step
before and 2nd we usually don't see the users as part of the
federation. The universities, institutes etc. are part of it. We have
contracts with them forcing them to fulfill minimum standards but not
with their users.
The way we see to get out of this is: Build your app, give it a
login-page that shows the login-website of a server that belongs to
your app and is part of the federation; login there; have the server
hand the necessary claims, tokens, whatever to the app. That way only
the server has to be part of the federation.
Does this clarify things?
Steffen
Am Do, 16.08.2018 um 17:09 schrieb Chris Phillips
<a class="moz-txt-link-rfc2396E" href="mailto:Chris.Phillips@canarie.ca"><Chris.Phillips@canarie.ca></a>:
</pre>
<blockquote type="cite">
<pre wrap="">I like the analogy Mike J however the example is an IdP of one -- the
bank or in other words a bi-lateral trust of one.
A multi-lateral federation context is different. It's more like a
neutral app that can be signed into by any number of Idps -- maybe
thousands of possible originations but within THAT circle of trust
and then do things.
When the bank writes the app, I'm sure they bake in things for their
interests, thus forcing copies of the same app over and over again
because it's bilaterally trusting things and the only delivery
container/security context is 'the app' because it's configured for
the bank it was built for.
It's not like I can download a 'transfer money app' and then sign
into any of my banks with it and perform the same function as if I
were within the same security context -- can I?
C
On 2018-08-16, 11:26 AM, "Openid-specs-ab on behalf of Mike Jones
via Openid-specs-ab" <a class="moz-txt-link-rfc2396E" href="mailto:openid-specs-ab-bounces@lists.openid.netonbehalfofopenid-specs-ab@lists.openid.net"><openid-specs-ab-bounces@lists.openid.net on
behalf of openid-specs-ab@lists.openid.net></a> wrote:
Thanks for writing, Steffen. For what it's worth, mobile
applications were one of the design points for OpenID Connect.
Connect is widely used for authenticating mobile applications, both
on Android and iOS (often using the AppAuth libraries supported by
this working group). At least as a thought experiment, it would seem
to me that since banks are somehow able to trust their mobile
applications sufficiently to let their customers perform financial
transactions with them, that surely we should be able to trust some
mobile applications sufficiently to let them participate in
federations. I'd encourage people who are experts in using Connect
with mobile applications to also weigh in on how to enable them in
federations. Best wishes, -- Mike -----Original Message----- From:
Openid-specs-ab <a class="moz-txt-link-rfc2396E" href="mailto:openid-specs-ab-bounces@lists.openid.net"><openid-specs-ab-bounces@lists.openid.net></a> On Behalf
Of Steffen Klemer via Openid-specs-ab Sent: Monday, August 6, 2018
1:54 AM To: <a class="moz-txt-link-abbreviated" href="mailto:openid-specs-ab@lists.openid.net">openid-specs-ab@lists.openid.net</a> Cc: Steffen Klemer
<a class="moz-txt-link-rfc2396E" href="mailto:klemer@dfn.de"><klemer@dfn.de></a> Subject: Re: [Openid-specs-ab] Comments on Solberg
JWT Federation Hey,
about this:
> I think that trends and new requirements would make it
> interesting to discuss the ability for SPAs and native apps to
> establish their own credentials (self generated key pairs).
> This will result in separate client_ids for each deployent,
> while the redirect_uris would be shared. How we build the
> federated infrastructure have consequences for how easy it
> would be to build and how smooth this will run.
I was thinking about the native app-scenario in a federation in
some length and couldn't find a way to extend the trust into the
mobile app; no matter which technology one assumes. The inherent
problem I see is the non-trustworthyness of the administrator of the
devices. You don't know her and even if you know her (by some
out-of-band mechanism of the app distribution) you can't know that
she doesn't tamper with your code or executes it in a tampered
environment. You can't trust that they do what they tell they do. The
point of federations as I understand them is that by some mechanism
you trust the entities. This can never be said about apps. To put it
differently: I'd say it's not worth to consider the app-client
scenario for the federation specs. Every time I discussed this with
people we ended in a scenario that somehow has an classical web
server as the federation entity/SP/RP that acts as some kind of proxy
for the app to get it trustworthy/secure from the point of view of
the federation. For example by handing it oauth-tokens after
federation login to access the secured content. It's very hard (for
me) to imagine a real-world app that needs some federation awareness
that does not use this knowledge to access other web services (e.g.
via oauth) but only locally stored data. (so the federation is used a
bit like a software-license server) Steffen -- DFN-Verein
Steffen Klemer Alexanderplatz 1 +49 30 884299 307 10178
Berlin <a class="moz-txt-link-abbreviated" href="mailto:klemer@dfn.de">klemer@dfn.de</a> Fax: 030 88 42 99 370
<a class="moz-txt-link-freetext" href="http://www.dfn.de">http://www.dfn.de</a> _______________________________________________
Openid-specs-ab mailing list <a class="moz-txt-link-abbreviated" href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a>
<a class="moz-txt-link-freetext" href="http://lists.openid.net/mailman/listinfo/openid-specs-ab">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a>
</pre>
</blockquote>
<pre wrap="">
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Openid-specs-ab mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a>
<a class="moz-txt-link-freetext" href="http://lists.openid.net/mailman/listinfo/openid-specs-ab">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a>
</pre>
</blockquote>
<br>
</body>
</html>