I prefer Mike's wording over Hannes's rewrite.
This is a design feature to leave it to specs like openID Connect to profile
what the values are. We did that in the context of what made sense for the
spec using the assertion profile.
I thought I also supported changing Principal to Subject on
There were some comments on the document made by Shawn Emery as part of a
security directorate's review
http://www.ietf.org/mail-archive/web/secdir/current/msg03679.html that seem
to have gotten lost in the shuffle.
His editorial comments are spot on and I believe the changes he suggests
should al
Same comment as Brian.I support Mike's proposed text.
-cmort
On Jan 18, 2013, at 3:32 PM, Brian Campbell wrote:
I apologize for not participating in much of the discussion around this - I've
been otherwise occupied this week with a myriad of other priorities at work.
I would, however, like
I apologize for not participating in much of the discussion around this -
I've been otherwise occupied this week with a myriad of other priorities at
work.
I would, however, like to voice my support in favor of the version of the
text that Mike proposed.
On Fri, Jan 18, 2013 at 3:59 PM, Mike Jon
I can't agree with proceeding with Hannes' rewrite of the interoperability
text, as editorially, it reads like it is apologizing for a defect in the
specification, whereas it is an intentional feature of the specification that
the syntax and verification rules of some fields is intentionally lef
Sent from BlackBerry® on Airtel
-Original Message-
From: oauth-requ...@ietf.org
Date: Fri, 18 Jan 2013 17:47:23
To:
Subject: OAuth Digest, Vol 51, Issue 58
If you have received this digest without all the individual message
attachments you will need to update your digest options in you
Hiya,
So I'll take the lack of further discussion about this an meaning
that the wg want this to shoot ahead. I'll put this in as an RFC
editor note for the draft.
Cheers,
S.
On 01/18/2013 12:04 PM, Tschofenig, Hannes (NSN - FI/Espoo) wrote:
> Hi all,
>
> As you have seen on the list (see
> h
Hi Hannes -
Providing localization support indirectly via the error_uri was the
conclusion that we were coming to, so thanks for responding and confirming
that.
Best wishes -- Todd
Todd Lainhart
Rational software
IBM Corporation
550 King Street, Littleton, MA 01460-1250
1-978-899-4705
2-27
Hi all,
As you have seen on the list (see
http://www.ietf.org/mail-archive/web/oauth/current/msg10526.html) I had
a chat with Mike about how to address my comment for the assertion draft
and Mike kindly provided his text proposal (see
http://www.ietf.org/mail-archive/web/oauth/current/msg10529.ht
Hi Todd,
it is important to note that the error_description is not meant to be shown to
the end users.
That was the reason for not introducing internationalization support.
If you want to provide some additional information about the error description
in other languages I would suggest to use
I have some questions concerning the oauth-security document.
1. collusion
Only collusion between resource servers are considered,
however, collusion between resource server and client could happen.
2. AS-to-RS relationship anonymity
if "the Client must not provide information about the R
11 matches
Mail list logo
