Re: [abfab] Direction Forward for aaa-saml

Alejandro Pérez Méndez <alex@um.es> Wed, 22 July 2015 21:28 UTC

Return-Path: <alex@um.es>
X-Original-To: abfab@ietfa.amsl.com
Delivered-To: abfab@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B08EB1B2E9E for <abfab@ietfa.amsl.com>; Wed, 22 Jul 2015 14:28:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.911
X-Spam-Level:
X-Spam-Status: No, score=-3.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jAJue_4WYujz for <abfab@ietfa.amsl.com>; Wed, 22 Jul 2015 14:28:51 -0700 (PDT)
Received: from xenon22.um.es (xenon22.um.es [155.54.212.162]) by ietfa.amsl.com (Postfix) with ESMTP id 2532D1B2E60 for <abfab@ietf.org>; Wed, 22 Jul 2015 14:28:51 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by xenon22.um.es (Postfix) with ESMTP id 26E6E1CC4 for <abfab@ietf.org>; Wed, 22 Jul 2015 23:28:49 +0200 (CEST)
X-Virus-Scanned: by antispam in UMU at xenon22.um.es
Received: from xenon22.um.es ([127.0.0.1]) by localhost (xenon22.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 1mGuEWc80JvS for <abfab@ietf.org>; Wed, 22 Jul 2015 23:28:49 +0200 (CEST)
Received: from [192.168.20.74] (186.160.broadband14.iol.cz [90.181.160.186]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: alex) by xenon22.um.es (Postfix) with ESMTPSA id DF357A7F for <abfab@ietf.org>; Wed, 22 Jul 2015 23:28:46 +0200 (CEST)
To: abfab@ietf.org
References: <tslwpxsy0ql.fsf@mit.edu> <8E4E5965-0E43-4ABD-8853-8A6C7C6926C5@mnt.se> <tsloaj4xzvr.fsf@mit.edu> <0B96365A-4F6B-427A-9A87-70F069473F84@mnt.se> <tsl7fpsxrve.fsf@mit.edu> <0A08B89E-5533-4E34-9014-97C0D7877B6E@osu.edu> <tslio9cw8yd.fsf@mit.edu> <D143C9FB-F878-49C1-89C4-6A494714A3EC@mnt.se> <tslegk0w7iw.fsf@mit.edu> <1FA8CCED-221E-4A88-B525-BF46FAA53A3F@mnt.se> <55AFC0E3.8030500@um.es> <tslpp3kuq2f.fsf@mit.edu> <55AFC24C.3070205@sunet.se> <tslh9owuptm.fsf@mit.edu> <55AFC37D.1040607@mnt.se> <tsl4mkwupis.fsf@mit.edu> <A03FA174-B811-4B78-96D7-4C18C84CB30B@osu.edu> <tslzj2otaps.fsf@mit.edu> <27CB306A-81E3-496E-8CBE-461CC58B8352@osu.edu> <55AFCAFC.6010903@sunet.se>
From: =?UTF-8?Q?Alejandro_P=c3=a9rez_M=c3=a9ndez?= <alex@um.es>
Message-ID: <55B00B0C.60005@um.es>
Date: Wed, 22 Jul 2015 23:28:44 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0
MIME-Version: 1.0
In-Reply-To: <55AFCAFC.6010903@sunet.se>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/abfab/v3uxvjcUQK-WNaKbo8HwjPUR6HM>
Subject: Re: [abfab] Direction Forward for aaa-saml
X-BeenThere: abfab@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" <abfab.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/abfab>, <mailto:abfab-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/abfab/>
List-Post: <mailto:abfab@ietf.org>
List-Help: <mailto:abfab-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/abfab>, <mailto:abfab-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Jul 2015 21:28:53 -0000


El 22/07/15 a las 18:55, Leif Johansson escribió:
> On 2015-07-22 18:36, Cantor, Scott wrote:
>>
>>
>>
>>
>> On 7/22/15, 12:31 PM, "Sam Hartman" <hartmans@painless-security.com> wrote:
>>
>>>>>>>> "Cantor," == Cantor, Scott <cantor.2@osu.edu> writes:
>>>
>>>     Cantor,> Leif's point is that if you don't specify any bindings, you
>>>     Cantor,> won't have any interop issue. But if you don't account for
>>>     Cantor,> the endpoint element(s) in the schema, you can't add them
>>>     Cantor,> later.
>>>
>>> O, that's irritating.
>> Well, it's not an absolute, you could do extensions to get them in later, but it's annoying to have to do that if you actually have a technical rationale for defining an endpoint type up front. It's better to just do it so it's a well-defined element and not buried inside an extension.
>>
>> Of course, you can make them minOccurs="0" initially so they're optional and don't matter for now.

Let me try to summarize, so I have a clear picture of what the next 
steps are:

in addition to add the new elements to the RADIUSIDPDescriptor and 
RADIUSRPDescriptor subtypes to include the naming information, we can 
keep the RADIUSIDPService and RADIUSRPService elements that I already 
defined (of type EndpointType, with minOccurs="0"), as a provision for 
the future use of locators/endpoints. We don't need to specify the 
specific URI format yet. Am I correct?

I have an additional question though. Leif mentioned that the URI format 
of the Locator attribute will be determined by the value of the Binding 
attribute, which is true. But, since in this document and section we are 
specifically defining the "urn:ietf:params:abfab:bindings:radius" 
Binding, shouldn't it be fixed to that value?

Regards,
Alejandro

>
> That was my thought
>
>
> _______________________________________________
> abfab mailing list
> abfab@ietf.org
> https://www.ietf.org/mailman/listinfo/abfab